[
https://issues.apache.org/activemq/browse/AMQ-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Grodberg updated AMQ-2080:
---------------------------------
I support the idea of different behavior before the discoveryAgent discovers a
broker as opposed to after, since the delay to discover a broker is a
completely different set of issues compared to the delay to connect to a broker
that is advertising that it is alive. Because of this, I think the different
behaviors should be completely separately configurable with regard to delay
between attempts, number of attempts, and backoff strategy.
In any case, though there may be good reasons it evolved this way, I find it
counter-intuitive and confusing that it would be the "reconnectDelay" and not
the "initialReconnectDelay" that is the reconnect delay used in the initial
attempt to find a broker.
For my immediate needs I can just deal with the current behavior, in part
because there is some other bug (perhaps in the JVM or the Win2K TCP stack)
that is causing any attempts to discover the broker to fail after the discovery
agent has been running for a few minutes. I suspect this is a Windows bug
because it affects other processes running in separate JVMs, but I'm not a
Windows expert so I don't know how reasonable it is to believe there's this
kind of bug still existing in the OS.
> InitialReconnectDelay appears to be ignored in Discovery transport URLs
> -----------------------------------------------------------------------
>
> Key: AMQ-2080
> URL: https://issues.apache.org/activemq/browse/AMQ-2080
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 5.2.0
> Environment: Windows XP SP3
> Reporter: Jeremy Grodberg
> Assignee: Gary Tully
>
> Using a connection URL of
> {{discovery:(multicast://default?group=test)?maxReconnectAttempts=13&initialReconnectDelay=1000&useExponentialBackOff=false}}
> one would expect initial connection attempts to go on for at least 13 seconds
> (13 reconnect attempts with 1000ms delay between attempts) but in fact the
> error "No uris available to connect to" returned in less than a second.
> Changing {{useExponentialBackOff}} to {{true}} delays a failure report to
> about 41 seconds, which is 10ms * 2^12, which is what you'd expect with 12
> reconnect attempts (13 connect attempts) starting with the default 10ms delay
> and doubling with every attempt, since 2^0+2^1+2^2+...2^n-1 is approx 2^n.
> (I guess maxReconnectAttempts should be called maxConnectAttempts, but I'm
> not opening a bug about that.) Changing maxReconnectAttempts to 12 causes
> the delay to be about 20 seconds, half of what it is for 13, so that checks
> out.
> Altogether this points to the initialReconnectDelay parameter being ignored
> on initial connection attempts. It is supposed to work per
> http://activemq.apache.org/discovery-transport-reference.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
