On Wed, Mar 18, 2015 at 1:10 AM, Fred Moore <fred.moor...@gmail.com> wrote: > > Questions: > > Q1\ Is this approach a viable one? > > Q2\ Are there better ways of obtaining a similar QoS (better in the sense > of ...more simple and/or more robust and/or more standard) > > Q3\ Are there any specific recommendations on which msgstore "flavor" to > pick up for a scenario like this? > > Q4\ Is there a way to specify a "preferred active node" for master/slave? > ...if there is not, we risk having both BrkA and BrkB running on, say, > Node1 and leaving Node2 unexploited (the problem here is not about > suboptimal balancing, but about having a short outage in case Node1 crashes > and both BrkA and BrkB will need to failover to Node2 at the same time).
I'm just getting started with ActiveMQ, and was posing some similar questions last week about the setup I've been considering. So what follows isnt advice, it's just a description of what we're planning on setting up and why. For our setup I considered high availability to be the goal, more so than pure speed or simplicity, so I discarded the options that require a shared persistence store. I wasn't comfortable having multiple brokers running on a single machine, so I am currently planning on having at least two sets of replicated leveldb brokers, each set networked to the other. For example: (1a,1b,1c) <-> (2a,2b,2c) which effectively gives me two active brokers (say 1a and 2a), and a failover capability on each (if 1a dies, either 1b or 1c would take over). The setup I'm planning on does depend on having a zookeeper cluster as well. With the setup I've been planning there isn't any need for me to specify a master, since the clients will be connecting with the failover scheme and I won't be having two brokers running on one node. But if I were, the replicated leveldb configuration lets you specify a "weight" option, telling it to give priority to a particular broker when it comes to the election. To prevent the problem of a message stuck on a broker, I am under the impression that there a few things I need to do with my setup: (a) Set up a networkBridgeFilterFactory in my configuration, specifying a conditionalNetworkBridgeFilterFactory with the option replayWhenNoConsumers="true". This should allow one active broker to send messages back to another active broker if it finds itself with messages and no consumers. (b) On the networkConnectors, set messageTTL="-1", and decreaseNetworkConsumerPriority="true". Setting messageTTL to -1 means a message can be passed though multiple brokers if necessary to get to an active consumer, and decreaseNetworkConsumerPriority weighs the number of broker hops a message would to take to reach a consumer, selecting the fewest hops. I'm also planning on setting the following on my transportConnector configuration: updateClusterClients="true" rebalanceClusterClients="true" updateClusterClientsOnRemove="true" These are intended to make the clients connect to another broker if we add or remove brokers from the network. Jim
