[ 
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.

Reply via email to