We have two brokers (running version 5.7) configured for failover and clients using the following broker configuration:
activemq.brokerUrl=failover:(tcp://hostA:61616,tcp://hostB:61616) However, at times the client will connect to one or the other broker and get a domain rebalance message to reconnect to tcp://0.0.0.0:61616. From the log file of the client: 2013-01-08 16:38:25,719 [ActiveMQ Task-2] DEBUG org.apache.activemq.transport.failover.FailoverTransport:881 - Doing rebalance from: tcp://hostA:61616 to [tcp://0.0.0.0:61616] 2013-01-08 16:38:25,720 [ActiveMQ Task-2] DEBUG org.apache.activemq.transport.tcp.TcpTransport:528 - Stopping transport tcp://hostA/10.1.1.1:61616 2013-01-08 16:38:25,721 [ActiveMQ Task-2] DEBUG org.apache.activemq.transport.failover.FailoverTransport:928 - Waiting 10 ms before attempting connection. 2013-01-08 16:38:25,733 [ActiveMQ Task-2] DEBUG org.apache.activemq.transport.failover.FailoverTransport:952 - Attempting 0th connect to: tcp://0.0.0.0:61616 2013-01-08 16:38:25,734 [ActiveMQ Task-2] DEBUG org.apache.activemq.transport.failover.FailoverTransport:1002 - Connect fail to: tcp://0.0.0.0:61616, reason: java.net.ConnectException: Connection refused Shutting down and restarting the broker seems to fix the problem temporarily, but then it comes back. I can't find a way to reproduce the problem on demand, but it does reoccur. Any ideas where I start to track this down? Is this a bug in activeMQ, or maybe something I'm doing wrong with the broker configuration for failover? Anyone ever see this problem before and know how to fix it? The trouble is that once this occurs, I can restart the client all day long, and it will still get tcp://0.0.0.0. The only way to fix it seems to be to bounce the broker, which is annoying in a production environment. -- View this message in context: http://activemq.2283324.n4.nabble.com/failover-broker-sending-clients-tcp-0-0-0-0-61616-as-rebalance-uri-tp4661518.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
