> Also, doing message replication is often times an anti-pattern in messaging because it creates split brain scenarios during many unplanned outages that require taking the entire cluster down to resend.
Split brain is certainly a potential risk that needs to be mitigated (as outlined in the documentation). However, at the very least replication unlocks some high-performance, highly-available use-cases that wouldn't be possible otherwise. I've seen successful, long-running broker deployments using replication with very stringent SLAs for both latency and availability. Of course, not every deployment is looking for such characteristics which is why other HA options are available (i.e. shared storage & shared database). As is often said, there are no perfect solutions, just trade-offs. Share store solutions, for example, introduce a single point of failure and overcoming that trade-off can require just as much "cost," if not more, that mitigating split-brain. Furthermore, the chance of split-brain even with a shared store configuration is not zero. Ultimately I think having options here is a nice win for users. Justin On Wed, May 22, 2024 at 4:18 PM Matt Pavlovich <mattr...@gmail.com> wrote: > Hi Marc- > > Scenarios when the queue shows up on a broker: > > 1. A message is delivered > 2. A producer, browser or consumer is connected > 3. A Virtual Destination subscriber queue is added on one broker and the > remote brokers automatically add them when the proper configuration flags > are enabled. > > The message movement ‘just works’ no matter where consumers connect in the > cluster. You don’t need to see the queue on all servers before hand for it > to function. > > Also, doing message replication is often times an anti-pattern in > messaging because it creates split brain scenarios during many unplanned > outages that require taking the entire cluster down to resend. > > Large ActiveMQ clusters often see better overall cluster uptime using VM > volumes, Kubernetes Volumes and infrastructure-level HA components vs > trying to replicate at the message broker layer. > > Best, > Matt Pavlovich > > > On May 22, 2024, at 2:40 PM, Marc Boorshtein <mboorsht...@gmail.com> > wrote: > > > > I've setup 3 brokers in Kubernetes as StatefulSets. Each one has its own > > unique broker name. In each broker config I setup a <networkConnectors> > > block similar to: > > > > <networkConnectors> > > <networkConnector name="amq0" > > > uri="static:(ssl://amq-orchestra-1.amq-ha.openunison.svc:61616,ssl://amq-orchestra-2.amq-ha.openunison.svc:61616)" > > /> > > </networkConnectors> > > > > Each broker connects to the other 2. Once all three are running i can > see > > in the logs that they're connecting: > > > > amq-orchestra > > INFO | Network connection between vm://amq0#24 and > > ssl://amq-orchestra-1.amq-ha.openunison.svc/10.244.0.252:61616 (amq1) > has > > been established. > > > > But when I create a queue in amq0, it doesn't appear in amq1. when I > > create the queue in both and send a message to it in amq0, it doesn't get > > forwarded to amq1 or amq2. > > > > I feel like I'm missing something really important, but I can't seem to > > work out what. Any help would be greatly appreciated. > > > > Thanks > > Marc > >
