I understand that this is only a problem when using the failover transport,
and clearly TCP connections to the master are working (otherwise you'd get
no connectivity at all no matter which host was the master).
What I'm trying to do is determine whether the problem (failure to detect
that the master goes down and is unavailable to make connections) is caused
by something in the failover transport (i.e. on the client side of the
connection) or in the broker.
To that end, I'd like you to please run the following tests, each from the
same starting point (host1 as master, host2 as slave, both having started
after you killed all brokers and all clients from the previous test, and no
consumer processes running):
1. Kill host1 so host2 becomes the master and there is no slave. Connect a
consumer with a URI of tcp://host1:61616. Does it connect? What's in the
consumer's logs?
2. Kill host1 so host2 becomes the master and there is no slave. Connect a
consumer with your normal failover URI. Does it connect? What's in the
consumer's logs?
3. Kill host1 so host2 becomes the master and there is no slave. Start
host1 so it becomes the slave. Kill host2 so host1 becomes the master and
there is no slave. Connect a consumer with your normal failover URI. Does
it connect? What's in the consumer's logs?
4. Remove the timeout attribute from your failover URI and try your
"regular" test again. You never mentioned that you were providing
additional options (randomize and timeout) to the failover URI, neither
here nor in the JIRA bug you submitted.
Also, I'm curious what's in the logs after the client timeout exceptions
you quoted. Can you post a longer snippet to show that?
Tim
On Jul 24, 2017 9:23 AM, "akpuvvada" <akp4ti...@gmail.com> wrote:
> Hi Tim,
> If I use the regular TCP URL, I am able to connect to the Active server
> anytime it is acting as Master.
> The issue is happening only if I use the failover URL.
>
> If I use the logic like try {connect to master} catch {connect to slave},
> it
> is working fine.
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Active-MQ-Master-Slave-Config-Not-working-
> tp4728550p4728832.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
