[
https://issues.apache.org/activemq/browse/AMQ-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Grodberg updated AMQ-2080:
---------------------------------
Description:
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
was:
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 11
reconnect attempts (12 connect attempts) starting with the default 10ms delay
and doubling with every attempt. (I'm not opening a bug on why it's 2^12
instead of 2^14 as I would expect it to be.) 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
> 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
>
> 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.
