activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <>
Subject Re: Queston: ActiveMQ client Failover - tcp
Date Sat, 14 May 2016 20:27:46 GMT
It's expected that you won't fail back to node1 when both are up (though
you can configure it to do so, see the Priority Backup section of, but it's
definitely not expected that you would not fail over to node1 if it was the
only live broker.

What do you see in the logs (the client and node1) when you take down
node2?  Also, how are you taking down node2?  From the remote end, it's not
possible to tell the difference between a non-graceful closure of a TCP
connection and a temporary network hiccup, so if you're doing kill -9 or
pulling the power cord or network cable, then your client might simply not
be detecting the broker failure.  ActiveMQ uses an InactivityMonitor to try
to detect connection failures that can't be detected from the TCP stack,
but I have personally observed behavior that makes me believe that it only
detects failures in some of the cases, and I've seen posts to this mailing
list that indicate that others have seen the same.  But if you do a clean
shutdown of the broker, I would expect failover to work in your scenario.

On May 14, 2016 10:41 AM, "aanto" <> wrote:

> I have been moving some of my clients to use the failover url using below.
> url=
> "failover:(tcp://node1:61616?useInactivityMonitor=false,
> tcp://node2:61616?useInactivityMonitor=false)?randomize=false;";
> I bring down node1,  client is able to read/write message by connecting to
> node2.
> Now, i bring back up node1, and bring down node2.
> I see that my client program does not read/write or failover to node1. I
> have to restart clients at this stage.
> Is this as designed ? or some issue that can be resolved by modifying
> configuration, so it can go round robin and connect to the one that is up.
> ?
> Thanks
> --
> View this message in context:
> Sent from the ActiveMQ - User mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message