FailoverTransport reconnecting too fast on Linux compared to Windows.

[mport9491]

I have one ActiveMQ broker on my Linux machine and a standalone Java
application that acts as a producer running on my Windows machine.

I specify my broker url to be to be:
failover://(tcp://10.0.112.49:61616)?timeout=1000&warnAfterReconnectAttempts=1&maxReconnectAttempts=0

Windows scenario:
I start my application and it automatically connects to the ActiveMQ broker.
When I stop the broker, the FailoverTransport tries to reconnect every
second.

2015-07-16 15:14:52,737 ERROR [ActiveMQ Task-1]
(FailoverTransport.java:1099) CSN: Failed to connect to
[tcp://10.0.112.49:61616] after: 1 attempt(s)

This is the expected behavior.

However, when I run the application on Linux, instead of trying to reconnect
every second, it reconnects every 5-10 milliseconds! I was wondering why the
behavior is different.



--
View this message in context: http://activemq.2283324.n4.nabble.com/FailoverTransport-reconnecting-too-fast-on-Linux-compared-to-Windows-tp4699410.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

[mport9491]

Also, what I've noticed is that maxReconnectAttempts=0 and
maxReconnectAttemps=1 have the same behavior. Is it intended to be this way?
I'm using ActiveMQ 5.11.1.

From version 5.6 onwards: -1 is default and means retry forever, 0 means
don't retry (only try connection once but no retry).
All versions: If set to >0, then this is the maximum number of reconnect
attempts before an error is sent back to the client.

So does this mean if your maxReconnectAttempts is either 0 or 1 then the
initial/maxReconnectDelay will not take effect?



--
View this message in context: http://activemq.2283324.n4.nabble.com/FailoverTransport-reconnecting-too-fast-on-Linux-compared-to-Windows-tp4699410p4699450.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

[Tim Bain]

It sounds like you're seeing exponential backoff disabled in Linux; if
exponential backoff is in use then the delay will increase quickly from
10ms up to whatever max is set (see lines 1145-1151 of
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-all/5.11.1/org/apache/activemq/transport/failover/FailoverTransport.java#FailoverTransport.doDelay%28%29),
but if it's disabled or if you've set a very small max reconnect delay
you'd keep retrying every 10ms. Is there any chance you've modified either
of those values in your URI on Linux but not on Windows? If not, you could
download the source for 5.11.1, load it into a project in your IDE of
choice, attach your IDE's debugger to the client, set a breakpoint on
FailoverTransport.doDelay(), and step through to see why exponential
backoff isn't taking effect on Linux.

As far as the maxReconnectAttempts, they do not have the same behavior. As
described in the documentation you quoted, one will attempt to reconnect
once, while the other will not attempt to reconnect. How are those the
same behavior?

Both settings of maxReconnectAttempts will not result in a delay between
reconnect attempts (because there will not be two consecutive reconnect
attempts), so you are correct, neither the initialReconnectDelay nor the
maxReconnectDelay will take effect.

Tim

Post by mport9491
Also, what I've noticed is that maxReconnectAttempts=0 and
maxReconnectAttemps=1 have the same behavior. Is it intended to be this way?
I'm using ActiveMQ 5.11.1.

From version 5.6 onwards: -1 is default and means retry forever, 0 means
don't retry (only try connection once but no retry).
All versions: If set to >0, then this is the maximum number of reconnect
attempts before an error is sent back to the client.

So does this mean if your maxReconnectAttempts is either 0 or 1 then the
initial/maxReconnectDelay will not take effect?
--
http://activemq.2283324.n4.nabble.com/FailoverTransport-reconnecting-too-fast-on-Linux-compared-to-Windows-tp4699410p4699450.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

[Tim Bain]

Scratch that. Your real question is, "Why does does a Socket.connect() on
Windows wait the full timeout period when attempting to connect to a host
that's down, while on Linux it fails almost immediately." You can probably
find that out using the debugger; set a breakpoint client at
FailoverTransport:1073 (the catch block of the try/catch in doReconnect())
and see whether the exception is the same in Windows vs. Linux and see if
that explains the difference.

Tim

Post by Tim Bain
It sounds like you're seeing exponential backoff disabled in Linux; if
exponential backoff is in use then the delay will increase quickly from
10ms up to whatever max is set (see lines 1145-1151 of
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-all/5.11.1/org/apache/activemq/transport/failover/FailoverTransport.java#FailoverTransport.doDelay%28%29),
but if it's disabled or if you've set a very small max reconnect delay
you'd keep retrying every 10ms. Is there any chance you've modified either
of those values in your URI on Linux but not on Windows? If not, you could
download the source for 5.11.1, load it into a project in your IDE of
choice, attach your IDE's debugger to the client, set a breakpoint on
FailoverTransport.doDelay(), and step through to see why exponential
backoff isn't taking effect on Linux.
As far as the maxReconnectAttempts, they do not have the same behavior.
As described in the documentation you quoted, one will attempt to reconnect
once, while the other will not attempt to reconnect. How are those the
same behavior?
Both settings of maxReconnectAttempts will not result in a delay between
reconnect attempts (because there will not be two consecutive reconnect
attempts), so you are correct, neither the initialReconnectDelay nor the
maxReconnectDelay will take effect.
Tim

Post by mport9491
Also, what I've noticed is that maxReconnectAttempts=0 and
maxReconnectAttemps=1 have the same behavior. Is it intended to be this way?
I'm using ActiveMQ 5.11.1.

From version 5.6 onwards: -1 is default and means retry forever, 0 means
don't retry (only try connection once but no retry).
All versions: If set to >0, then this is the maximum number of reconnect
attempts before an error is sent back to the client.

So does this mean if your maxReconnectAttempts is either 0 or 1 then the
initial/maxReconnectDelay will not take effect?
--
http://activemq.2283324.n4.nabble.com/FailoverTransport-reconnecting-too-fast-on-Linux-compared-to-Windows-tp4699410p4699450.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.