Hi Jason, There currently isn't any support in the Java broker for federation / store+forward to distribute messages between brokers, if you wanted to do that you would need to use a separate bridging process.
The optional BDB-HA store replicates the durable configuration and persistent messages (non-persistent mesages are not replicated) at the virtualhost level. Current work has mainly been done around the 2-node case with explicit use of the associated 'designated-primary' flag to control what happens when a node goes down, there is a split-brain scenario, etc. Technically there is nothing preventing configuring an N-node BDB-HA cluster with use of simple majority voting for handling split-brain etc, but there are some interesting behaviours that occur when doing so which would require a non-trivial amount of additional work to allow the virtualhosts to actively monitor the cluster to account for and alter their own behaviour accordingly (right now its mostly the reverse, with the virtualhosts simply reacting to notification from the underlying BDB-HA store nodes regarding their state, which is pretty clear cut in the 2-node case) to ensure the overall system acted more in line with general expectation. Robbie On 17 April 2013 14:58, Jason Barto <[email protected]> wrote: > All, > I've benchmarked my qpid broker (java) at 70k msg/s with a single producer > / consumer scenario and am now turning my eye towards ha deployment. I see > from the documentation that a 2 node master / slave is supported on > clustering. What about distributed nodes for load balancing? > > Is there any mechanism for having say 3 master / slave setups with > federation like rabbitmq or store/forward like activemq? > > The goal is to have an always on 5 9s deployment. > > Sincerely, > Jason >
