It's not clear exactly what is meant here by "corruption," but I think it's probably the wrong word to describe the issues caused by split-brain. The brokers should be able to read all the data in the journals no problem. The actual problems are more related to potential duplicate consumption or missed messages.
Regarding duplicate consumption, consider 2 JMS consumers listening on a queue on the master broker. Those consumers would be competing for the same messages such that each message would only be consumed once (i.e. by either consumer). However, once split brain occurs you could potentially have a consumer on the same queue on *each* broker. In that case, they could each receive the same message since they were no longer competing with each other. Regarding missed messages, consider a non-durable JMS topic subscriber. While it's connected to the master it receives every message sent to the topic. However, once split brain occurs the producer might send messages to the broker where the subscriber isn't connected which means it wouldn't get those messages. In short, the data on each broker should stay 100% in-tact from a technical stand-point. The problem is more in the realm of "irreconcilable differences" for the applications connected to the brokers. The simplest way to mitigate split-brain is to use a shared-store. However, if a shared-store is not viable for your use-case the next best solution is to integrate with ZooKeeper via the pluggable quorum vote replication configuration [1]. Justin [1] https://activemq.apache.org/components/artemis/documentation/latest/ha.html#pluggable-quorum-vote-replication-configurations On Thu, Apr 7, 2022 at 9:53 PM Steigerwald, Aaron <asteigerw...@brandesassociates.com.invalid> wrote: > Hello, > > My colleague has read that split brain can cause journal corruption in a > master/slave network replication scenario. Is anyone aware if this is > possible with current versions of Artemis? > > Thank you, > Aaron Steigerwald >
