Hi, I guess: 1. The broker sends the rebalance control messages to your client and your client do rebalance and reconnect to the other broker; 2. The second broker has some consumers while none on the first broker so messages sent to the first broker are forwarded to the second broker by demand. 3. Failover transport may misbehave in your case where enabling rebalanceClusterClients option of TransportConnector and backup option of FailoverTransport while disabling randomize option of FailoverTransport .
At 2013-01-22 12:24:27,"Nate Faerber" <[email protected]> wrote: >Hi, > >I have two ActiveMQ server configured as network of brokers and my clients >with this connect string: > >failover:(tcp://mq1-master:61616,tcp://mq2-master:61616)?randomize=false&backup=true&maxReconnectDelay=10000 > >It seems that every time we create a JMS message using Spring Framework, >the ActiveMQ connection, our clients try the primary then fail to the >secondary. The large (large) majority of messages go through the second >ActiveMQ server. This seems like an inefficiency or at least does not >behave like I would expect it to. Am I misunderstanding the configuration >here? > >2013-01-21 20:10:27,604 INFO > [org.apache.activemq.transport.failover.FailoverTransport][ActiveMQ >Task-1] [FailoverTransport.java:1030] Successfully connected to >tcp://mq1-master:61616 >2013-01-21 20:10:27,610 INFO > [org.apache.activemq.transport.failover.FailoverTransport][ActiveMQ >Task-1] [FailoverTransport.java:1032] Successfully reconnected to >tcp://mq2-master:61616 > >My servers have this config: > > <transportConnectors> > <transportConnector > name="${broker.transport.client.name}" > uri="${broker.transport.client.uri}" > updateClusterClients="true" > updateClusterClientsOnRemove="true" > rebalanceClusterClients="true" /> > > <transportConnector > name="${broker.transport.network.name}" > uri="${broker.transport.network.uri}" /> > </transportConnectors> > >Thoughts appreciated. > >thanks, >-nate
