[
https://issues.apache.org/activemq/browse/AMQ-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully resolved AMQ-2080.
-----------------------------
Resolution: Working as Designed
Fix Version/s: 5.2.0
agree, it is not intuitive, but the original value of the reconnectDelay is in
use prior to the discovery component returning a list of candidate urls to
connect to.
Added a reference to the documentation:
http://activemq.apache.org/discovery-transport-reference.html
Re your current problem, I think it is unlikely to be a JVM of OS issue.
Have you enabled debug logging for the class:
org.apache.activemq.transport.discovery.multicast.MulticastDiscoveryAgent to
see if there is any indicator there. Some of the configuration options on the
[MulticastDiscoveryAgent|http://activemq.apache.org/maven/5.2.0/activemq-core/apidocs/src-html/org/apache/activemq/transport/discovery/multicast/MulticastDiscoveryAgent.html]
may not be appropriate to your scenario.
The discoveryAgent properties are set like the group attribute:
{code}discovery:(multicast://default?group=test&keepAliveInterval=1000)...{code}
> 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
> Fix For: 5.2.0
>
>
> 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.