[
https://issues.apache.org/activemq/browse/AMQ-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=48953#action_48953
]
Gary Tully commented on AMQ-2080:
---------------------------------
the initialReconnectDelay kicks in when a candidate url is returned by the
discovery agent. Up to that point, the reconnectDelay is in effect and this
defaults to 10 ms. I think there is some value in leaving things are they are
such that it is possible to have a different initial reconnect delay for
discovery finding some candidate urls and for connecting to these urls.
I added a test that verifies the setting of reconnectDelay takes effect when no
broker can be found. It uses a uri of the form:
"discovery:{code}(multicast://default)?useExponentialBackOff=false&maxReconnectAttempts=2&reconnectDelay=4000{code}
Does this work for you. If so I can update the documentation with a reference
to reconnectDelay
> 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.
