activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Grodberg (JIRA)" <j...@apache.org>
Subject [jira] Updated: (AMQ-2080) InitialReconnectDelay appears to be ignored in Discovery transport URLs
Date Mon, 26 Jan 2009 19:54:59 GMT

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


Mime
View raw message