Static: network connectors and maxReconnectAttempts

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Static: network connectors and maxReconnectAttempts

Tim Bain
Gary, Torsten, and others have said in various places that broker-to-broker
networkConnectors should set maxReconnectAttempts=0 to allow reconnection
to be handled by the network bridge.  (Sources: 1
<http://tmielke.blogspot.com/2011/09/activemq-network-bridge-to-masterslave.html>,
2
<http://activemq.2283324.n4.nabble.com/Persistent-messages-disappearing-td4681353.html>,
3
<http://grokbase.com/t/activemq/users/1427v9eqkf/prioritybackup-not-supported-with-masterslave>)
Torsten (link 1) was talking about static: network connectors, while Gary's
quotes in the other two links were related to failover: (or masterslave:,
which is just chrome on top of failover:), but if it's a requirement of the
network bridge that it be the one to re-establish the question, it
shouldn't matter what the underlying transport is.

It's obvious in FailoverTransport
<http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-client/5.10.0/org/apache/activemq/transport/failover/FailoverTransport.java#FailoverTransport>
how maxReconnectAttempts=0 gets processed to mean "don't try to reconnect",
allowing the network bridge to re-establish the connection, and there are
notes in http://activemq.apache.org/failover-transport-reference.html
explaining that this interpretation of the value "0" was implemented in
5.6.0 (https://issues.apache.org/jira/browse/AMQ-3542).  There's no similar
code in SimpleDiscoveryAgent
<http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-all/5.10.0/org/apache/activemq/transport/discovery/simple/SimpleDiscoveryAgent.java#SimpleDiscoveryAgent>
(which handles connection attempts for the static: transport
<http://activemq.apache.org/static-transport-reference.html>, as I
understand it) to interpret "-1" as "reconnect forever" and "0" as "don't
reconnect".

Is Gary's and Torsten's advice about maxReconnectAttempts not applicable to
static: network connectors for some reason that I'm not understanding?  Or
should the changes Gary made in AMQ-3542 have been applied to all protocols
that include reconnection attempts?  (Do I need to open a JIRA for this?)

And a related question: when using the static: transport to establish a
broker mesh, if we set maxReconnectAttempts=0, is there a way to perform
exponential backoff at the network bridge, so it doesn't continually try to
reconnect (and spam the logs) when one broker in the mesh is offline for a
while?  The only way I see to control exponential backoff is within the
static: transport via the useExponentialBackOff=true option; searching the
source code (I'm looking at 5.8.0), I don't see any references to
exponential backoff in any code that seems to be related to network
bridges...

Thanks,
Tim
Reply | Threaded
Open this post in threaded view
|

Re: Static: network connectors and maxReconnectAttempts

gtully
maxReconnectAttempts=0 relates to the use of failover only, where you use
failover to choose between a list of broker urls (typically a pair for
master slave). masterSlave sets maxReconnectAttempts=0 on the underlying
failover url.
The static discovery, which is implemented by the SimpleDiscoveryAgent can
do retries and backoff etc.
see:
https://github.com/apache/activemq/blob/d54e0d6ab590b6a6148a5e2629c45b95d3f40eb8/activemq-client/src/main/java/org/apache/activemq/transport/discovery/simple/SimpleDiscoveryAgent.java#L42

The network bridge is a discovery listener, it gets told to add/remove
services (urls) that are discovered/retried.


On 24 September 2014 20:20, Tim Bain <[hidden email]> wrote:

> Gary, Torsten, and others have said in various places that broker-to-broker
> networkConnectors should set maxReconnectAttempts=0 to allow reconnection
> to be handled by the network bridge.  (Sources: 1
> <
> http://tmielke.blogspot.com/2011/09/activemq-network-bridge-to-masterslave.html
> >,
> 2
> <
> http://activemq.2283324.n4.nabble.com/Persistent-messages-disappearing-td4681353.html
> >,
> 3
> <
> http://grokbase.com/t/activemq/users/1427v9eqkf/prioritybackup-not-supported-with-masterslave
> >)
> Torsten (link 1) was talking about static: network connectors, while Gary's
> quotes in the other two links were related to failover: (or masterslave:,
> which is just chrome on top of failover:), but if it's a requirement of the
> network bridge that it be the one to re-establish the question, it
> shouldn't matter what the underlying transport is.
>
> It's obvious in FailoverTransport
> <
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-client/5.10.0/org/apache/activemq/transport/failover/FailoverTransport.java#FailoverTransport
> >
> how maxReconnectAttempts=0 gets processed to mean "don't try to reconnect",
> allowing the network bridge to re-establish the connection, and there are
> notes in http://activemq.apache.org/failover-transport-reference.html
> explaining that this interpretation of the value "0" was implemented in
> 5.6.0 (https://issues.apache.org/jira/browse/AMQ-3542).  There's no
> similar
> code in SimpleDiscoveryAgent
> <
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-all/5.10.0/org/apache/activemq/transport/discovery/simple/SimpleDiscoveryAgent.java#SimpleDiscoveryAgent
> >
> (which handles connection attempts for the static: transport
> <http://activemq.apache.org/static-transport-reference.html>, as I
> understand it) to interpret "-1" as "reconnect forever" and "0" as "don't
> reconnect".
>
> Is Gary's and Torsten's advice about maxReconnectAttempts not applicable to
> static: network connectors for some reason that I'm not understanding?  Or
> should the changes Gary made in AMQ-3542 have been applied to all protocols
> that include reconnection attempts?  (Do I need to open a JIRA for this?)
>
> And a related question: when using the static: transport to establish a
> broker mesh, if we set maxReconnectAttempts=0, is there a way to perform
> exponential backoff at the network bridge, so it doesn't continually try to
> reconnect (and spam the logs) when one broker in the mesh is offline for a
> while?  The only way I see to control exponential backoff is within the
> static: transport via the useExponentialBackOff=true option; searching the
> source code (I'm looking at 5.8.0), I don't see any references to
> exponential backoff in any code that seems to be related to network
> bridges...
>
> Thanks,
> Tim
>



--
http://redhat.com
http://blog.garytully.com
Reply | Threaded
Open this post in threaded view
|

Re: Static: network connectors and maxReconnectAttempts

Tim Bain
Based on the comments that you and Torsten made in the links from my first
message, I had understood that for networkConnectors between brokers, you
should not allow the discovery transport to perform reconnects, because it
was important for the network bridge to be notified of the disconnection
and reconnection.  You said that that happens automatically for static
discovery transports (and I see the onServiceAdd() and onServiceRemove()
methods in NetworkDiscoveryConnector that would handle those events), but
what's different about failover that makes the same DiscoveryListener
mechanism not work?

On Thu, Sep 25, 2014 at 9:21 AM, Gary Tully <[hidden email]> wrote:

> maxReconnectAttempts=0 relates to the use of failover only, where you use
> failover to choose between a list of broker urls (typically a pair for
> master slave). masterSlave sets maxReconnectAttempts=0 on the underlying
> failover url.
> The static discovery, which is implemented by the SimpleDiscoveryAgent can
> do retries and backoff etc.
> see:
>
> https://github.com/apache/activemq/blob/d54e0d6ab590b6a6148a5e2629c45b95d3f40eb8/activemq-client/src/main/java/org/apache/activemq/transport/discovery/simple/SimpleDiscoveryAgent.java#L42
>
> The network bridge is a discovery listener, it gets told to add/remove
> services (urls) that are discovered/retried.
>
>
> On 24 September 2014 20:20, Tim Bain <[hidden email]> wrote:
>
> > Gary, Torsten, and others have said in various places that
> broker-to-broker
> > networkConnectors should set maxReconnectAttempts=0 to allow reconnection
> > to be handled by the network bridge.  (Sources: 1
> > <
> >
> http://tmielke.blogspot.com/2011/09/activemq-network-bridge-to-masterslave.html
> > >,
> > 2
> > <
> >
> http://activemq.2283324.n4.nabble.com/Persistent-messages-disappearing-td4681353.html
> > >,
> > 3
> > <
> >
> http://grokbase.com/t/activemq/users/1427v9eqkf/prioritybackup-not-supported-with-masterslave
> > >)
> > Torsten (link 1) was talking about static: network connectors, while
> Gary's
> > quotes in the other two links were related to failover: (or masterslave:,
> > which is just chrome on top of failover:), but if it's a requirement of
> the
> > network bridge that it be the one to re-establish the question, it
> > shouldn't matter what the underlying transport is.
> >
> > It's obvious in FailoverTransport
> > <
> >
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-client/5.10.0/org/apache/activemq/transport/failover/FailoverTransport.java#FailoverTransport
> > >
> > how maxReconnectAttempts=0 gets processed to mean "don't try to
> reconnect",
> > allowing the network bridge to re-establish the connection, and there are
> > notes in http://activemq.apache.org/failover-transport-reference.html
> > explaining that this interpretation of the value "0" was implemented in
> > 5.6.0 (https://issues.apache.org/jira/browse/AMQ-3542).  There's no
> > similar
> > code in SimpleDiscoveryAgent
> > <
> >
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-all/5.10.0/org/apache/activemq/transport/discovery/simple/SimpleDiscoveryAgent.java#SimpleDiscoveryAgent
> > >
> > (which handles connection attempts for the static: transport
> > <http://activemq.apache.org/static-transport-reference.html>, as I
> > understand it) to interpret "-1" as "reconnect forever" and "0" as "don't
> > reconnect".
> >
> > Is Gary's and Torsten's advice about maxReconnectAttempts not applicable
> to
> > static: network connectors for some reason that I'm not understanding?
> Or
> > should the changes Gary made in AMQ-3542 have been applied to all
> protocols
> > that include reconnection attempts?  (Do I need to open a JIRA for this?)
> >
> > And a related question: when using the static: transport to establish a
> > broker mesh, if we set maxReconnectAttempts=0, is there a way to perform
> > exponential backoff at the network bridge, so it doesn't continually try
> to
> > reconnect (and spam the logs) when one broker in the mesh is offline for
> a
> > while?  The only way I see to control exponential backoff is within the
> > static: transport via the useExponentialBackOff=true option; searching
> the
> > source code (I'm looking at 5.8.0), I don't see any references to
> > exponential backoff in any code that seems to be related to network
> > bridges...
> >
> > Thanks,
> > Tim
> >
>
>
>
> --
> http://redhat.com
> http://blog.garytully.com
>
Reply | Threaded
Open this post in threaded view
|

Re: Static: network connectors and maxReconnectAttempts

gtully
the failover transport maintains a bunch of state -
connections/sessons/producers/consumers/transactions/messags/acks so that
it can replay those to maintain and recreate the jms client view.
However, a netwok bridge is not a standard jms client - specifically in the
duplex case but I think there potential issues in the non duplex case also.
So a failover reconnect will not guarantee that the network bridge is fully
functional. The bridge needs to be stopped and restarted to successfully
cleanup and resume.
In other words, the network bridge needs to be aware of transport failures
as they occur. The intent of the failover: transport is to hide those.



On 25 September 2014 19:37, Tim Bain <[hidden email]> wrote:

> Based on the comments that you and Torsten made in the links from my first
> message, I had understood that for networkConnectors between brokers, you
> should not allow the discovery transport to perform reconnects, because it
> was important for the network bridge to be notified of the disconnection
> and reconnection.  You said that that happens automatically for static
> discovery transports (and I see the onServiceAdd() and onServiceRemove()
> methods in NetworkDiscoveryConnector that would handle those events), but
> what's different about failover that makes the same DiscoveryListener
> mechanism not work?
>
> On Thu, Sep 25, 2014 at 9:21 AM, Gary Tully <[hidden email]> wrote:
>
> > maxReconnectAttempts=0 relates to the use of failover only, where you use
> > failover to choose between a list of broker urls (typically a pair for
> > master slave). masterSlave sets maxReconnectAttempts=0 on the underlying
> > failover url.
> > The static discovery, which is implemented by the SimpleDiscoveryAgent
> can
> > do retries and backoff etc.
> > see:
> >
> >
> https://github.com/apache/activemq/blob/d54e0d6ab590b6a6148a5e2629c45b95d3f40eb8/activemq-client/src/main/java/org/apache/activemq/transport/discovery/simple/SimpleDiscoveryAgent.java#L42
> >
> > The network bridge is a discovery listener, it gets told to add/remove
> > services (urls) that are discovered/retried.
> >
> >
> > On 24 September 2014 20:20, Tim Bain <[hidden email]> wrote:
> >
> > > Gary, Torsten, and others have said in various places that
> > broker-to-broker
> > > networkConnectors should set maxReconnectAttempts=0 to allow
> reconnection
> > > to be handled by the network bridge.  (Sources: 1
> > > <
> > >
> >
> http://tmielke.blogspot.com/2011/09/activemq-network-bridge-to-masterslave.html
> > > >,
> > > 2
> > > <
> > >
> >
> http://activemq.2283324.n4.nabble.com/Persistent-messages-disappearing-td4681353.html
> > > >,
> > > 3
> > > <
> > >
> >
> http://grokbase.com/t/activemq/users/1427v9eqkf/prioritybackup-not-supported-with-masterslave
> > > >)
> > > Torsten (link 1) was talking about static: network connectors, while
> > Gary's
> > > quotes in the other two links were related to failover: (or
> masterslave:,
> > > which is just chrome on top of failover:), but if it's a requirement of
> > the
> > > network bridge that it be the one to re-establish the question, it
> > > shouldn't matter what the underlying transport is.
> > >
> > > It's obvious in FailoverTransport
> > > <
> > >
> >
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-client/5.10.0/org/apache/activemq/transport/failover/FailoverTransport.java#FailoverTransport
> > > >
> > > how maxReconnectAttempts=0 gets processed to mean "don't try to
> > reconnect",
> > > allowing the network bridge to re-establish the connection, and there
> are
> > > notes in http://activemq.apache.org/failover-transport-reference.html
> > > explaining that this interpretation of the value "0" was implemented in
> > > 5.6.0 (https://issues.apache.org/jira/browse/AMQ-3542).  There's no
> > > similar
> > > code in SimpleDiscoveryAgent
> > > <
> > >
> >
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-all/5.10.0/org/apache/activemq/transport/discovery/simple/SimpleDiscoveryAgent.java#SimpleDiscoveryAgent
> > > >
> > > (which handles connection attempts for the static: transport
> > > <http://activemq.apache.org/static-transport-reference.html>, as I
> > > understand it) to interpret "-1" as "reconnect forever" and "0" as
> "don't
> > > reconnect".
> > >
> > > Is Gary's and Torsten's advice about maxReconnectAttempts not
> applicable
> > to
> > > static: network connectors for some reason that I'm not understanding?
> > Or
> > > should the changes Gary made in AMQ-3542 have been applied to all
> > protocols
> > > that include reconnection attempts?  (Do I need to open a JIRA for
> this?)
> > >
> > > And a related question: when using the static: transport to establish a
> > > broker mesh, if we set maxReconnectAttempts=0, is there a way to
> perform
> > > exponential backoff at the network bridge, so it doesn't continually
> try
> > to
> > > reconnect (and spam the logs) when one broker in the mesh is offline
> for
> > a
> > > while?  The only way I see to control exponential backoff is within the
> > > static: transport via the useExponentialBackOff=true option; searching
> > the
> > > source code (I'm looking at 5.8.0), I don't see any references to
> > > exponential backoff in any code that seems to be related to network
> > > bridges...
> > >
> > > Thanks,
> > > Tim
> > >
> >
> >
> >
> > --
> > http://redhat.com
> > http://blog.garytully.com
> >
>



--
http://redhat.com
http://blog.garytully.com
Reply | Threaded
Open this post in threaded view
|

Re: Static: network connectors and maxReconnectAttempts

Tim Bain
Would it be possible for the failover transport to use the same
DiscoveryListener mechanism that the static transport uses, but that's just
not how it's been implemented?  Or is there something fundamental about why
static is allowed to do its own reconnections (notifying the bridge via the
event handlers on the bridge's DiscoveryListener interface) but failover
has to let connection failures bubble up to the bridge?

Thanks for taking the time to clarify this, by the way.

On Fri, Sep 26, 2014 at 4:14 AM, Gary Tully <[hidden email]> wrote:

> the failover transport maintains a bunch of state -
> connections/sessons/producers/consumers/transactions/messags/acks so that
> it can replay those to maintain and recreate the jms client view.
> However, a netwok bridge is not a standard jms client - specifically in the
> duplex case but I think there potential issues in the non duplex case also.
> So a failover reconnect will not guarantee that the network bridge is fully
> functional. The bridge needs to be stopped and restarted to successfully
> cleanup and resume.
> In other words, the network bridge needs to be aware of transport failures
> as they occur. The intent of the failover: transport is to hide those.
>
>
>
> On 25 September 2014 19:37, Tim Bain <[hidden email]> wrote:
>
> > Based on the comments that you and Torsten made in the links from my
> first
> > message, I had understood that for networkConnectors between brokers, you
> > should not allow the discovery transport to perform reconnects, because
> it
> > was important for the network bridge to be notified of the disconnection
> > and reconnection.  You said that that happens automatically for static
> > discovery transports (and I see the onServiceAdd() and onServiceRemove()
> > methods in NetworkDiscoveryConnector that would handle those events), but
> > what's different about failover that makes the same DiscoveryListener
> > mechanism not work?
> >
> > On Thu, Sep 25, 2014 at 9:21 AM, Gary Tully <[hidden email]>
> wrote:
> >
> > > maxReconnectAttempts=0 relates to the use of failover only, where you
> use
> > > failover to choose between a list of broker urls (typically a pair for
> > > master slave). masterSlave sets maxReconnectAttempts=0 on the
> underlying
> > > failover url.
> > > The static discovery, which is implemented by the SimpleDiscoveryAgent
> > can
> > > do retries and backoff etc.
> > > see:
> > >
> > >
> >
> https://github.com/apache/activemq/blob/d54e0d6ab590b6a6148a5e2629c45b95d3f40eb8/activemq-client/src/main/java/org/apache/activemq/transport/discovery/simple/SimpleDiscoveryAgent.java#L42
> > >
> > > The network bridge is a discovery listener, it gets told to add/remove
> > > services (urls) that are discovered/retried.
> > >
> > >
> > > On 24 September 2014 20:20, Tim Bain <[hidden email]> wrote:
> > >
> > > > Gary, Torsten, and others have said in various places that
> > > broker-to-broker
> > > > networkConnectors should set maxReconnectAttempts=0 to allow
> > reconnection
> > > > to be handled by the network bridge.  (Sources: 1
> > > > <
> > > >
> > >
> >
> http://tmielke.blogspot.com/2011/09/activemq-network-bridge-to-masterslave.html
> > > > >,
> > > > 2
> > > > <
> > > >
> > >
> >
> http://activemq.2283324.n4.nabble.com/Persistent-messages-disappearing-td4681353.html
> > > > >,
> > > > 3
> > > > <
> > > >
> > >
> >
> http://grokbase.com/t/activemq/users/1427v9eqkf/prioritybackup-not-supported-with-masterslave
> > > > >)
> > > > Torsten (link 1) was talking about static: network connectors, while
> > > Gary's
> > > > quotes in the other two links were related to failover: (or
> > masterslave:,
> > > > which is just chrome on top of failover:), but if it's a requirement
> of
> > > the
> > > > network bridge that it be the one to re-establish the question, it
> > > > shouldn't matter what the underlying transport is.
> > > >
> > > > It's obvious in FailoverTransport
> > > > <
> > > >
> > >
> >
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-client/5.10.0/org/apache/activemq/transport/failover/FailoverTransport.java#FailoverTransport
> > > > >
> > > > how maxReconnectAttempts=0 gets processed to mean "don't try to
> > > reconnect",
> > > > allowing the network bridge to re-establish the connection, and there
> > are
> > > > notes in
> http://activemq.apache.org/failover-transport-reference.html
> > > > explaining that this interpretation of the value "0" was implemented
> in
> > > > 5.6.0 (https://issues.apache.org/jira/browse/AMQ-3542).  There's no
> > > > similar
> > > > code in SimpleDiscoveryAgent
> > > > <
> > > >
> > >
> >
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-all/5.10.0/org/apache/activemq/transport/discovery/simple/SimpleDiscoveryAgent.java#SimpleDiscoveryAgent
> > > > >
> > > > (which handles connection attempts for the static: transport
> > > > <http://activemq.apache.org/static-transport-reference.html>, as I
> > > > understand it) to interpret "-1" as "reconnect forever" and "0" as
> > "don't
> > > > reconnect".
> > > >
> > > > Is Gary's and Torsten's advice about maxReconnectAttempts not
> > applicable
> > > to
> > > > static: network connectors for some reason that I'm not
> understanding?
> > > Or
> > > > should the changes Gary made in AMQ-3542 have been applied to all
> > > protocols
> > > > that include reconnection attempts?  (Do I need to open a JIRA for
> > this?)
> > > >
> > > > And a related question: when using the static: transport to
> establish a
> > > > broker mesh, if we set maxReconnectAttempts=0, is there a way to
> > perform
> > > > exponential backoff at the network bridge, so it doesn't continually
> > try
> > > to
> > > > reconnect (and spam the logs) when one broker in the mesh is offline
> > for
> > > a
> > > > while?  The only way I see to control exponential backoff is within
> the
> > > > static: transport via the useExponentialBackOff=true option;
> searching
> > > the
> > > > source code (I'm looking at 5.8.0), I don't see any references to
> > > > exponential backoff in any code that seems to be related to network
> > > > bridges...
> > > >
> > > > Thanks,
> > > > Tim
> > > >
> > >
> > >
> > >
> > > --
> > > http://redhat.com
> > > http://blog.garytully.com
> > >
> >
>
>
>
> --
> http://redhat.com
> http://blog.garytully.com
>
Reply | Threaded
Open this post in threaded view
|

Re: Static: network connectors and maxReconnectAttempts

gtully
everything is possible! but they evolved independently, hence the overlap
in functionality

On 26 September 2014 16:02, Tim Bain <[hidden email]> wrote:

> Would it be possible for the failover transport to use the same
> DiscoveryListener mechanism that the static transport uses, but that's just
> not how it's been implemented?  Or is there something fundamental about why
> static is allowed to do its own reconnections (notifying the bridge via the
> event handlers on the bridge's DiscoveryListener interface) but failover
> has to let connection failures bubble up to the bridge?
>
> Thanks for taking the time to clarify this, by the way.
>
> On Fri, Sep 26, 2014 at 4:14 AM, Gary Tully <[hidden email]> wrote:
>
> > the failover transport maintains a bunch of state -
> > connections/sessons/producers/consumers/transactions/messags/acks so that
> > it can replay those to maintain and recreate the jms client view.
> > However, a netwok bridge is not a standard jms client - specifically in
> the
> > duplex case but I think there potential issues in the non duplex case
> also.
> > So a failover reconnect will not guarantee that the network bridge is
> fully
> > functional. The bridge needs to be stopped and restarted to successfully
> > cleanup and resume.
> > In other words, the network bridge needs to be aware of transport
> failures
> > as they occur. The intent of the failover: transport is to hide those.
> >
> >
> >
> > On 25 September 2014 19:37, Tim Bain <[hidden email]> wrote:
> >
> > > Based on the comments that you and Torsten made in the links from my
> > first
> > > message, I had understood that for networkConnectors between brokers,
> you
> > > should not allow the discovery transport to perform reconnects, because
> > it
> > > was important for the network bridge to be notified of the
> disconnection
> > > and reconnection.  You said that that happens automatically for static
> > > discovery transports (and I see the onServiceAdd() and
> onServiceRemove()
> > > methods in NetworkDiscoveryConnector that would handle those events),
> but
> > > what's different about failover that makes the same DiscoveryListener
> > > mechanism not work?
> > >
> > > On Thu, Sep 25, 2014 at 9:21 AM, Gary Tully <[hidden email]>
> > wrote:
> > >
> > > > maxReconnectAttempts=0 relates to the use of failover only, where you
> > use
> > > > failover to choose between a list of broker urls (typically a pair
> for
> > > > master slave). masterSlave sets maxReconnectAttempts=0 on the
> > underlying
> > > > failover url.
> > > > The static discovery, which is implemented by the
> SimpleDiscoveryAgent
> > > can
> > > > do retries and backoff etc.
> > > > see:
> > > >
> > > >
> > >
> >
> https://github.com/apache/activemq/blob/d54e0d6ab590b6a6148a5e2629c45b95d3f40eb8/activemq-client/src/main/java/org/apache/activemq/transport/discovery/simple/SimpleDiscoveryAgent.java#L42
> > > >
> > > > The network bridge is a discovery listener, it gets told to
> add/remove
> > > > services (urls) that are discovered/retried.
> > > >
> > > >
> > > > On 24 September 2014 20:20, Tim Bain <[hidden email]> wrote:
> > > >
> > > > > Gary, Torsten, and others have said in various places that
> > > > broker-to-broker
> > > > > networkConnectors should set maxReconnectAttempts=0 to allow
> > > reconnection
> > > > > to be handled by the network bridge.  (Sources: 1
> > > > > <
> > > > >
> > > >
> > >
> >
> http://tmielke.blogspot.com/2011/09/activemq-network-bridge-to-masterslave.html
> > > > > >,
> > > > > 2
> > > > > <
> > > > >
> > > >
> > >
> >
> http://activemq.2283324.n4.nabble.com/Persistent-messages-disappearing-td4681353.html
> > > > > >,
> > > > > 3
> > > > > <
> > > > >
> > > >
> > >
> >
> http://grokbase.com/t/activemq/users/1427v9eqkf/prioritybackup-not-supported-with-masterslave
> > > > > >)
> > > > > Torsten (link 1) was talking about static: network connectors,
> while
> > > > Gary's
> > > > > quotes in the other two links were related to failover: (or
> > > masterslave:,
> > > > > which is just chrome on top of failover:), but if it's a
> requirement
> > of
> > > > the
> > > > > network bridge that it be the one to re-establish the question, it
> > > > > shouldn't matter what the underlying transport is.
> > > > >
> > > > > It's obvious in FailoverTransport
> > > > > <
> > > > >
> > > >
> > >
> >
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-client/5.10.0/org/apache/activemq/transport/failover/FailoverTransport.java#FailoverTransport
> > > > > >
> > > > > how maxReconnectAttempts=0 gets processed to mean "don't try to
> > > > reconnect",
> > > > > allowing the network bridge to re-establish the connection, and
> there
> > > are
> > > > > notes in
> > http://activemq.apache.org/failover-transport-reference.html
> > > > > explaining that this interpretation of the value "0" was
> implemented
> > in
> > > > > 5.6.0 (https://issues.apache.org/jira/browse/AMQ-3542).  There's
> no
> > > > > similar
> > > > > code in SimpleDiscoveryAgent
> > > > > <
> > > > >
> > > >
> > >
> >
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-all/5.10.0/org/apache/activemq/transport/discovery/simple/SimpleDiscoveryAgent.java#SimpleDiscoveryAgent
> > > > > >
> > > > > (which handles connection attempts for the static: transport
> > > > > <http://activemq.apache.org/static-transport-reference.html>, as I
> > > > > understand it) to interpret "-1" as "reconnect forever" and "0" as
> > > "don't
> > > > > reconnect".
> > > > >
> > > > > Is Gary's and Torsten's advice about maxReconnectAttempts not
> > > applicable
> > > > to
> > > > > static: network connectors for some reason that I'm not
> > understanding?
> > > > Or
> > > > > should the changes Gary made in AMQ-3542 have been applied to all
> > > > protocols
> > > > > that include reconnection attempts?  (Do I need to open a JIRA for
> > > this?)
> > > > >
> > > > > And a related question: when using the static: transport to
> > establish a
> > > > > broker mesh, if we set maxReconnectAttempts=0, is there a way to
> > > perform
> > > > > exponential backoff at the network bridge, so it doesn't
> continually
> > > try
> > > > to
> > > > > reconnect (and spam the logs) when one broker in the mesh is
> offline
> > > for
> > > > a
> > > > > while?  The only way I see to control exponential backoff is within
> > the
> > > > > static: transport via the useExponentialBackOff=true option;
> > searching
> > > > the
> > > > > source code (I'm looking at 5.8.0), I don't see any references to
> > > > > exponential backoff in any code that seems to be related to network
> > > > > bridges...
> > > > >
> > > > > Thanks,
> > > > > Tim
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > http://redhat.com
> > > > http://blog.garytully.com
> > > >
> > >
> >
> >
> >
> > --
> > http://redhat.com
> > http://blog.garytully.com
> >
>



--
http://redhat.com
http://blog.garytully.com
Reply | Threaded
Open this post in threaded view
|

Re: Static: network connectors and maxReconnectAttempts

Tim Bain
Sounds good; thanks for the explanation.

On Mon, Sep 29, 2014 at 4:17 AM, Gary Tully <[hidden email]> wrote:

> everything is possible! but they evolved independently, hence the overlap
> in functionality
>
> On 26 September 2014 16:02, Tim Bain <[hidden email]> wrote:
>
> > Would it be possible for the failover transport to use the same
> > DiscoveryListener mechanism that the static transport uses, but that's
> just
> > not how it's been implemented?  Or is there something fundamental about
> why
> > static is allowed to do its own reconnections (notifying the bridge via
> the
> > event handlers on the bridge's DiscoveryListener interface) but failover
> > has to let connection failures bubble up to the bridge?
> >
> > Thanks for taking the time to clarify this, by the way.
> >
> > On Fri, Sep 26, 2014 at 4:14 AM, Gary Tully <[hidden email]>
> wrote:
> >
> > > the failover transport maintains a bunch of state -
> > > connections/sessons/producers/consumers/transactions/messags/acks so
> that
> > > it can replay those to maintain and recreate the jms client view.
> > > However, a netwok bridge is not a standard jms client - specifically in
> > the
> > > duplex case but I think there potential issues in the non duplex case
> > also.
> > > So a failover reconnect will not guarantee that the network bridge is
> > fully
> > > functional. The bridge needs to be stopped and restarted to
> successfully
> > > cleanup and resume.
> > > In other words, the network bridge needs to be aware of transport
> > failures
> > > as they occur. The intent of the failover: transport is to hide those.
> > >
> > >
> > >
> > > On 25 September 2014 19:37, Tim Bain <[hidden email]> wrote:
> > >
> > > > Based on the comments that you and Torsten made in the links from my
> > > first
> > > > message, I had understood that for networkConnectors between brokers,
> > you
> > > > should not allow the discovery transport to perform reconnects,
> because
> > > it
> > > > was important for the network bridge to be notified of the
> > disconnection
> > > > and reconnection.  You said that that happens automatically for
> static
> > > > discovery transports (and I see the onServiceAdd() and
> > onServiceRemove()
> > > > methods in NetworkDiscoveryConnector that would handle those events),
> > but
> > > > what's different about failover that makes the same DiscoveryListener
> > > > mechanism not work?
> > > >
> > > > On Thu, Sep 25, 2014 at 9:21 AM, Gary Tully <[hidden email]>
> > > wrote:
> > > >
> > > > > maxReconnectAttempts=0 relates to the use of failover only, where
> you
> > > use
> > > > > failover to choose between a list of broker urls (typically a pair
> > for
> > > > > master slave). masterSlave sets maxReconnectAttempts=0 on the
> > > underlying
> > > > > failover url.
> > > > > The static discovery, which is implemented by the
> > SimpleDiscoveryAgent
> > > > can
> > > > > do retries and backoff etc.
> > > > > see:
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/activemq/blob/d54e0d6ab590b6a6148a5e2629c45b95d3f40eb8/activemq-client/src/main/java/org/apache/activemq/transport/discovery/simple/SimpleDiscoveryAgent.java#L42
> > > > >
> > > > > The network bridge is a discovery listener, it gets told to
> > add/remove
> > > > > services (urls) that are discovered/retried.
> > > > >
> > > > >
> > > > > On 24 September 2014 20:20, Tim Bain <[hidden email]>
> wrote:
> > > > >
> > > > > > Gary, Torsten, and others have said in various places that
> > > > > broker-to-broker
> > > > > > networkConnectors should set maxReconnectAttempts=0 to allow
> > > > reconnection
> > > > > > to be handled by the network bridge.  (Sources: 1
> > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tmielke.blogspot.com/2011/09/activemq-network-bridge-to-masterslave.html
> > > > > > >,
> > > > > > 2
> > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> http://activemq.2283324.n4.nabble.com/Persistent-messages-disappearing-td4681353.html
> > > > > > >,
> > > > > > 3
> > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> http://grokbase.com/t/activemq/users/1427v9eqkf/prioritybackup-not-supported-with-masterslave
> > > > > > >)
> > > > > > Torsten (link 1) was talking about static: network connectors,
> > while
> > > > > Gary's
> > > > > > quotes in the other two links were related to failover: (or
> > > > masterslave:,
> > > > > > which is just chrome on top of failover:), but if it's a
> > requirement
> > > of
> > > > > the
> > > > > > network bridge that it be the one to re-establish the question,
> it
> > > > > > shouldn't matter what the underlying transport is.
> > > > > >
> > > > > > It's obvious in FailoverTransport
> > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-client/5.10.0/org/apache/activemq/transport/failover/FailoverTransport.java#FailoverTransport
> > > > > > >
> > > > > > how maxReconnectAttempts=0 gets processed to mean "don't try to
> > > > > reconnect",
> > > > > > allowing the network bridge to re-establish the connection, and
> > there
> > > > are
> > > > > > notes in
> > > http://activemq.apache.org/failover-transport-reference.html
> > > > > > explaining that this interpretation of the value "0" was
> > implemented
> > > in
> > > > > > 5.6.0 (https://issues.apache.org/jira/browse/AMQ-3542).  There's
> > no
> > > > > > similar
> > > > > > code in SimpleDiscoveryAgent
> > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-all/5.10.0/org/apache/activemq/transport/discovery/simple/SimpleDiscoveryAgent.java#SimpleDiscoveryAgent
> > > > > > >
> > > > > > (which handles connection attempts for the static: transport
> > > > > > <http://activemq.apache.org/static-transport-reference.html>,
> as I
> > > > > > understand it) to interpret "-1" as "reconnect forever" and "0"
> as
> > > > "don't
> > > > > > reconnect".
> > > > > >
> > > > > > Is Gary's and Torsten's advice about maxReconnectAttempts not
> > > > applicable
> > > > > to
> > > > > > static: network connectors for some reason that I'm not
> > > understanding?
> > > > > Or
> > > > > > should the changes Gary made in AMQ-3542 have been applied to all
> > > > > protocols
> > > > > > that include reconnection attempts?  (Do I need to open a JIRA
> for
> > > > this?)
> > > > > >
> > > > > > And a related question: when using the static: transport to
> > > establish a
> > > > > > broker mesh, if we set maxReconnectAttempts=0, is there a way to
> > > > perform
> > > > > > exponential backoff at the network bridge, so it doesn't
> > continually
> > > > try
> > > > > to
> > > > > > reconnect (and spam the logs) when one broker in the mesh is
> > offline
> > > > for
> > > > > a
> > > > > > while?  The only way I see to control exponential backoff is
> within
> > > the
> > > > > > static: transport via the useExponentialBackOff=true option;
> > > searching
> > > > > the
> > > > > > source code (I'm looking at 5.8.0), I don't see any references to
> > > > > > exponential backoff in any code that seems to be related to
> network
> > > > > > bridges...
> > > > > >
> > > > > > Thanks,
> > > > > > Tim
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > http://redhat.com
> > > > > http://blog.garytully.com
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > http://redhat.com
> > > http://blog.garytully.com
> > >
> >
>
>
>
> --
> http://redhat.com
> http://blog.garytully.com
>
Reply | Threaded
Open this post in threaded view
|

Re: Static: network connectors and maxReconnectAttempts

Tim Bain
Gary,

I was able to get failover working between brokers in a network of brokers
using the maxReconnectAttempts=0 URI option.  However, when I tried adding
priorityBackup=true, I ran into problems.
http://activemq.2283324.n4.nabble.com/priorityBackup-not-supported-with-masterslave-td4677626.html#a4677945
and https://issues.apache.org/jira/browse/AMQ-4720 indicate that
priorityBackup won't work with broker-to-broker failover connections, for
the same reasons you and I went through last month.

For us, this makes failover networkConnectors (including ones using the
masterslave transport, since it's just chrome on top of failover) useless,
since our goal is to minimize the number of hops a message has to take and
the lack of fail-back behavior on the broker-to-broker connections
introduces an extra hop when messages continue going to the backup and then
have to be forwarded to the primary where all the clients now are.  For us,
a static mesh is better than a failover network that will have this
sub-optimal routing, so we'll stay with that until the static transport is
able to handle failover transports with the priorityBackup option enabled.

I looked in JIRA and couldn't find any enhancement request for making the
static transport handle this gracefully (your comments on
https://issues.apache.org/jira/browse/AMQ-4720 do indicate that that's what
would need to happen to fix that bug, but I think it's better as a
stand-alone request), so I submitted
https://issues.apache.org/jira/browse/AMQ-5411 to capture it.

But I think there's also a workaround that could be implemented: if
maxReconnects=0, when the priority connection is established following a
failover, the failover transport can kill both connections (the old one to
the backup broker and the new one to the priority broker), let the failure
bubble up to the static transport, and let it use the failover transport to
reconnect (to the priority URI, since it's now up).  I've submitted
https://issues.apache.org/jira/browse/AMQ-5412 to capture that workaround
request, in case doing the full rewrite described in AMQ-5411 isn't an
option in the near term.

Tim

On Mon, Sep 29, 2014 at 9:51 AM, Tim Bain <[hidden email]> wrote:

> Sounds good; thanks for the explanation.
>
> On Mon, Sep 29, 2014 at 4:17 AM, Gary Tully <[hidden email]> wrote:
>
>> everything is possible! but they evolved independently, hence the overlap
>> in functionality
>>
>> On 26 September 2014 16:02, Tim Bain <[hidden email]> wrote:
>>
>> > Would it be possible for the failover transport to use the same
>> > DiscoveryListener mechanism that the static transport uses, but that's
>> just
>> > not how it's been implemented?  Or is there something fundamental about
>> why
>> > static is allowed to do its own reconnections (notifying the bridge via
>> the
>> > event handlers on the bridge's DiscoveryListener interface) but failover
>> > has to let connection failures bubble up to the bridge?
>> >
>> > Thanks for taking the time to clarify this, by the way.
>> >
>> > On Fri, Sep 26, 2014 at 4:14 AM, Gary Tully <[hidden email]>
>> wrote:
>> >
>> > > the failover transport maintains a bunch of state -
>> > > connections/sessons/producers/consumers/transactions/messags/acks so
>> that
>> > > it can replay those to maintain and recreate the jms client view.
>> > > However, a netwok bridge is not a standard jms client - specifically
>> in
>> > the
>> > > duplex case but I think there potential issues in the non duplex case
>> > also.
>> > > So a failover reconnect will not guarantee that the network bridge is
>> > fully
>> > > functional. The bridge needs to be stopped and restarted to
>> successfully
>> > > cleanup and resume.
>> > > In other words, the network bridge needs to be aware of transport
>> > failures
>> > > as they occur. The intent of the failover: transport is to hide those.
>> > >
>> > >
>> > >
>> > > On 25 September 2014 19:37, Tim Bain <[hidden email]> wrote:
>> > >
>> > > > Based on the comments that you and Torsten made in the links from my
>> > > first
>> > > > message, I had understood that for networkConnectors between
>> brokers,
>> > you
>> > > > should not allow the discovery transport to perform reconnects,
>> because
>> > > it
>> > > > was important for the network bridge to be notified of the
>> > disconnection
>> > > > and reconnection.  You said that that happens automatically for
>> static
>> > > > discovery transports (and I see the onServiceAdd() and
>> > onServiceRemove()
>> > > > methods in NetworkDiscoveryConnector that would handle those
>> events),
>> > but
>> > > > what's different about failover that makes the same
>> DiscoveryListener
>> > > > mechanism not work?
>> > > >
>> > > > On Thu, Sep 25, 2014 at 9:21 AM, Gary Tully <[hidden email]>
>> > > wrote:
>> > > >
>> > > > > maxReconnectAttempts=0 relates to the use of failover only, where
>> you
>> > > use
>> > > > > failover to choose between a list of broker urls (typically a pair
>> > for
>> > > > > master slave). masterSlave sets maxReconnectAttempts=0 on the
>> > > underlying
>> > > > > failover url.
>> > > > > The static discovery, which is implemented by the
>> > SimpleDiscoveryAgent
>> > > > can
>> > > > > do retries and backoff etc.
>> > > > > see:
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/activemq/blob/d54e0d6ab590b6a6148a5e2629c45b95d3f40eb8/activemq-client/src/main/java/org/apache/activemq/transport/discovery/simple/SimpleDiscoveryAgent.java#L42
>> > > > >
>> > > > > The network bridge is a discovery listener, it gets told to
>> > add/remove
>> > > > > services (urls) that are discovered/retried.
>> > > > >
>> > > > >
>> > > > > On 24 September 2014 20:20, Tim Bain <[hidden email]>
>> wrote:
>> > > > >
>> > > > > > Gary, Torsten, and others have said in various places that
>> > > > > broker-to-broker
>> > > > > > networkConnectors should set maxReconnectAttempts=0 to allow
>> > > > reconnection
>> > > > > > to be handled by the network bridge.  (Sources: 1
>> > > > > > <
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> http://tmielke.blogspot.com/2011/09/activemq-network-bridge-to-masterslave.html
>> > > > > > >,
>> > > > > > 2
>> > > > > > <
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> http://activemq.2283324.n4.nabble.com/Persistent-messages-disappearing-td4681353.html
>> > > > > > >,
>> > > > > > 3
>> > > > > > <
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> http://grokbase.com/t/activemq/users/1427v9eqkf/prioritybackup-not-supported-with-masterslave
>> > > > > > >)
>> > > > > > Torsten (link 1) was talking about static: network connectors,
>> > while
>> > > > > Gary's
>> > > > > > quotes in the other two links were related to failover: (or
>> > > > masterslave:,
>> > > > > > which is just chrome on top of failover:), but if it's a
>> > requirement
>> > > of
>> > > > > the
>> > > > > > network bridge that it be the one to re-establish the question,
>> it
>> > > > > > shouldn't matter what the underlying transport is.
>> > > > > >
>> > > > > > It's obvious in FailoverTransport
>> > > > > > <
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-client/5.10.0/org/apache/activemq/transport/failover/FailoverTransport.java#FailoverTransport
>> > > > > > >
>> > > > > > how maxReconnectAttempts=0 gets processed to mean "don't try to
>> > > > > reconnect",
>> > > > > > allowing the network bridge to re-establish the connection, and
>> > there
>> > > > are
>> > > > > > notes in
>> > > http://activemq.apache.org/failover-transport-reference.html
>> > > > > > explaining that this interpretation of the value "0" was
>> > implemented
>> > > in
>> > > > > > 5.6.0 (https://issues.apache.org/jira/browse/AMQ-3542).
>> There's
>> > no
>> > > > > > similar
>> > > > > > code in SimpleDiscoveryAgent
>> > > > > > <
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-all/5.10.0/org/apache/activemq/transport/discovery/simple/SimpleDiscoveryAgent.java#SimpleDiscoveryAgent
>> > > > > > >
>> > > > > > (which handles connection attempts for the static: transport
>> > > > > > <http://activemq.apache.org/static-transport-reference.html>,
>> as I
>> > > > > > understand it) to interpret "-1" as "reconnect forever" and "0"
>> as
>> > > > "don't
>> > > > > > reconnect".
>> > > > > >
>> > > > > > Is Gary's and Torsten's advice about maxReconnectAttempts not
>> > > > applicable
>> > > > > to
>> > > > > > static: network connectors for some reason that I'm not
>> > > understanding?
>> > > > > Or
>> > > > > > should the changes Gary made in AMQ-3542 have been applied to
>> all
>> > > > > protocols
>> > > > > > that include reconnection attempts?  (Do I need to open a JIRA
>> for
>> > > > this?)
>> > > > > >
>> > > > > > And a related question: when using the static: transport to
>> > > establish a
>> > > > > > broker mesh, if we set maxReconnectAttempts=0, is there a way to
>> > > > perform
>> > > > > > exponential backoff at the network bridge, so it doesn't
>> > continually
>> > > > try
>> > > > > to
>> > > > > > reconnect (and spam the logs) when one broker in the mesh is
>> > offline
>> > > > for
>> > > > > a
>> > > > > > while?  The only way I see to control exponential backoff is
>> within
>> > > the
>> > > > > > static: transport via the useExponentialBackOff=true option;
>> > > searching
>> > > > > the
>> > > > > > source code (I'm looking at 5.8.0), I don't see any references
>> to
>> > > > > > exponential backoff in any code that seems to be related to
>> network
>> > > > > > bridges...
>> > > > > >
>> > > > > > Thanks,
>> > > > > > Tim
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > http://redhat.com
>> > > > > http://blog.garytully.com
>> > > > >
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > http://redhat.com
>> > > http://blog.garytully.com
>> > >
>> >
>>
>>
>>
>> --
>> http://redhat.com
>> http://blog.garytully.com
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Static: network connectors and maxReconnectAttempts

gtully
you may be able to achieve what you want with two network connectors. one
to the primary and one to the backup. When both are alive and you use
decreaseNetworkConsumerPriority and priority dispatch, messages should take
the shortest path (priority decreases with number of hops).

On 24 October 2014 21:14, Tim Bain <[hidden email]> wrote:

> Gary,
>
> I was able to get failover working between brokers in a network of brokers
> using the maxReconnectAttempts=0 URI option.  However, when I tried adding
> priorityBackup=true, I ran into problems.
>
> http://activemq.2283324.n4.nabble.com/priorityBackup-not-supported-with-masterslave-td4677626.html#a4677945
> and https://issues.apache.org/jira/browse/AMQ-4720 indicate that
> priorityBackup won't work with broker-to-broker failover connections, for
> the same reasons you and I went through last month.
>
> For us, this makes failover networkConnectors (including ones using the
> masterslave transport, since it's just chrome on top of failover) useless,
> since our goal is to minimize the number of hops a message has to take and
> the lack of fail-back behavior on the broker-to-broker connections
> introduces an extra hop when messages continue going to the backup and then
> have to be forwarded to the primary where all the clients now are.  For us,
> a static mesh is better than a failover network that will have this
> sub-optimal routing, so we'll stay with that until the static transport is
> able to handle failover transports with the priorityBackup option enabled.
>
> I looked in JIRA and couldn't find any enhancement request for making the
> static transport handle this gracefully (your comments on
> https://issues.apache.org/jira/browse/AMQ-4720 do indicate that that's
> what
> would need to happen to fix that bug, but I think it's better as a
> stand-alone request), so I submitted
> https://issues.apache.org/jira/browse/AMQ-5411 to capture it.
>
> But I think there's also a workaround that could be implemented: if
> maxReconnects=0, when the priority connection is established following a
> failover, the failover transport can kill both connections (the old one to
> the backup broker and the new one to the priority broker), let the failure
> bubble up to the static transport, and let it use the failover transport to
> reconnect (to the priority URI, since it's now up).  I've submitted
> https://issues.apache.org/jira/browse/AMQ-5412 to capture that workaround
> request, in case doing the full rewrite described in AMQ-5411 isn't an
> option in the near term.
>
> Tim
>
> On Mon, Sep 29, 2014 at 9:51 AM, Tim Bain <[hidden email]> wrote:
>
> > Sounds good; thanks for the explanation.
> >
> > On Mon, Sep 29, 2014 at 4:17 AM, Gary Tully <[hidden email]>
> wrote:
> >
> >> everything is possible! but they evolved independently, hence the
> overlap
> >> in functionality
> >>
> >> On 26 September 2014 16:02, Tim Bain <[hidden email]> wrote:
> >>
> >> > Would it be possible for the failover transport to use the same
> >> > DiscoveryListener mechanism that the static transport uses, but that's
> >> just
> >> > not how it's been implemented?  Or is there something fundamental
> about
> >> why
> >> > static is allowed to do its own reconnections (notifying the bridge
> via
> >> the
> >> > event handlers on the bridge's DiscoveryListener interface) but
> failover
> >> > has to let connection failures bubble up to the bridge?
> >> >
> >> > Thanks for taking the time to clarify this, by the way.
> >> >
> >> > On Fri, Sep 26, 2014 at 4:14 AM, Gary Tully <[hidden email]>
> >> wrote:
> >> >
> >> > > the failover transport maintains a bunch of state -
> >> > > connections/sessons/producers/consumers/transactions/messags/acks so
> >> that
> >> > > it can replay those to maintain and recreate the jms client view.
> >> > > However, a netwok bridge is not a standard jms client - specifically
> >> in
> >> > the
> >> > > duplex case but I think there potential issues in the non duplex
> case
> >> > also.
> >> > > So a failover reconnect will not guarantee that the network bridge
> is
> >> > fully
> >> > > functional. The bridge needs to be stopped and restarted to
> >> successfully
> >> > > cleanup and resume.
> >> > > In other words, the network bridge needs to be aware of transport
> >> > failures
> >> > > as they occur. The intent of the failover: transport is to hide
> those.
> >> > >
> >> > >
> >> > >
> >> > > On 25 September 2014 19:37, Tim Bain <[hidden email]> wrote:
> >> > >
> >> > > > Based on the comments that you and Torsten made in the links from
> my
> >> > > first
> >> > > > message, I had understood that for networkConnectors between
> >> brokers,
> >> > you
> >> > > > should not allow the discovery transport to perform reconnects,
> >> because
> >> > > it
> >> > > > was important for the network bridge to be notified of the
> >> > disconnection
> >> > > > and reconnection.  You said that that happens automatically for
> >> static
> >> > > > discovery transports (and I see the onServiceAdd() and
> >> > onServiceRemove()
> >> > > > methods in NetworkDiscoveryConnector that would handle those
> >> events),
> >> > but
> >> > > > what's different about failover that makes the same
> >> DiscoveryListener
> >> > > > mechanism not work?
> >> > > >
> >> > > > On Thu, Sep 25, 2014 at 9:21 AM, Gary Tully <[hidden email]
> >
> >> > > wrote:
> >> > > >
> >> > > > > maxReconnectAttempts=0 relates to the use of failover only,
> where
> >> you
> >> > > use
> >> > > > > failover to choose between a list of broker urls (typically a
> pair
> >> > for
> >> > > > > master slave). masterSlave sets maxReconnectAttempts=0 on the
> >> > > underlying
> >> > > > > failover url.
> >> > > > > The static discovery, which is implemented by the
> >> > SimpleDiscoveryAgent
> >> > > > can
> >> > > > > do retries and backoff etc.
> >> > > > > see:
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/apache/activemq/blob/d54e0d6ab590b6a6148a5e2629c45b95d3f40eb8/activemq-client/src/main/java/org/apache/activemq/transport/discovery/simple/SimpleDiscoveryAgent.java#L42
> >> > > > >
> >> > > > > The network bridge is a discovery listener, it gets told to
> >> > add/remove
> >> > > > > services (urls) that are discovered/retried.
> >> > > > >
> >> > > > >
> >> > > > > On 24 September 2014 20:20, Tim Bain <[hidden email]>
> >> wrote:
> >> > > > >
> >> > > > > > Gary, Torsten, and others have said in various places that
> >> > > > > broker-to-broker
> >> > > > > > networkConnectors should set maxReconnectAttempts=0 to allow
> >> > > > reconnection
> >> > > > > > to be handled by the network bridge.  (Sources: 1
> >> > > > > > <
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> http://tmielke.blogspot.com/2011/09/activemq-network-bridge-to-masterslave.html
> >> > > > > > >,
> >> > > > > > 2
> >> > > > > > <
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> http://activemq.2283324.n4.nabble.com/Persistent-messages-disappearing-td4681353.html
> >> > > > > > >,
> >> > > > > > 3
> >> > > > > > <
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> http://grokbase.com/t/activemq/users/1427v9eqkf/prioritybackup-not-supported-with-masterslave
> >> > > > > > >)
> >> > > > > > Torsten (link 1) was talking about static: network connectors,
> >> > while
> >> > > > > Gary's
> >> > > > > > quotes in the other two links were related to failover: (or
> >> > > > masterslave:,
> >> > > > > > which is just chrome on top of failover:), but if it's a
> >> > requirement
> >> > > of
> >> > > > > the
> >> > > > > > network bridge that it be the one to re-establish the
> question,
> >> it
> >> > > > > > shouldn't matter what the underlying transport is.
> >> > > > > >
> >> > > > > > It's obvious in FailoverTransport
> >> > > > > > <
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-client/5.10.0/org/apache/activemq/transport/failover/FailoverTransport.java#FailoverTransport
> >> > > > > > >
> >> > > > > > how maxReconnectAttempts=0 gets processed to mean "don't try
> to
> >> > > > > reconnect",
> >> > > > > > allowing the network bridge to re-establish the connection,
> and
> >> > there
> >> > > > are
> >> > > > > > notes in
> >> > > http://activemq.apache.org/failover-transport-reference.html
> >> > > > > > explaining that this interpretation of the value "0" was
> >> > implemented
> >> > > in
> >> > > > > > 5.6.0 (https://issues.apache.org/jira/browse/AMQ-3542).
> >> There's
> >> > no
> >> > > > > > similar
> >> > > > > > code in SimpleDiscoveryAgent
> >> > > > > > <
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-all/5.10.0/org/apache/activemq/transport/discovery/simple/SimpleDiscoveryAgent.java#SimpleDiscoveryAgent
> >> > > > > > >
> >> > > > > > (which handles connection attempts for the static: transport
> >> > > > > > <http://activemq.apache.org/static-transport-reference.html>,
> >> as I
> >> > > > > > understand it) to interpret "-1" as "reconnect forever" and
> "0"
> >> as
> >> > > > "don't
> >> > > > > > reconnect".
> >> > > > > >
> >> > > > > > Is Gary's and Torsten's advice about maxReconnectAttempts not
> >> > > > applicable
> >> > > > > to
> >> > > > > > static: network connectors for some reason that I'm not
> >> > > understanding?
> >> > > > > Or
> >> > > > > > should the changes Gary made in AMQ-3542 have been applied to
> >> all
> >> > > > > protocols
> >> > > > > > that include reconnection attempts?  (Do I need to open a JIRA
> >> for
> >> > > > this?)
> >> > > > > >
> >> > > > > > And a related question: when using the static: transport to
> >> > > establish a
> >> > > > > > broker mesh, if we set maxReconnectAttempts=0, is there a way
> to
> >> > > > perform
> >> > > > > > exponential backoff at the network bridge, so it doesn't
> >> > continually
> >> > > > try
> >> > > > > to
> >> > > > > > reconnect (and spam the logs) when one broker in the mesh is
> >> > offline
> >> > > > for
> >> > > > > a
> >> > > > > > while?  The only way I see to control exponential backoff is
> >> within
> >> > > the
> >> > > > > > static: transport via the useExponentialBackOff=true option;
> >> > > searching
> >> > > > > the
> >> > > > > > source code (I'm looking at 5.8.0), I don't see any references
> >> to
> >> > > > > > exponential backoff in any code that seems to be related to
> >> network
> >> > > > > > bridges...
> >> > > > > >
> >> > > > > > Thanks,
> >> > > > > > Tim
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > --
> >> > > > > http://redhat.com
> >> > > > > http://blog.garytully.com
> >> > > > >
> >> > > >
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > http://redhat.com
> >> > > http://blog.garytully.com
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> http://redhat.com
> >> http://blog.garytully.com
> >>
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Static: network connectors and maxReconnectAttempts

Tim Bain
What you're suggesting sounds like it would behave the same as if I use the
static: transport with two nested URIs, except that I'd have more
configuration boilerplate since I'd have an additional networkConnector on
which I'd have to set all of my config options.  Do I get something from
using the two networkConnectors that I don't get from using a static:
transport with two nested URIs?  If not, I'll stay with the simpler config,
until priorityBackup works with networkConnectors.

On Thu, Oct 30, 2014 at 5:53 AM, Gary Tully <[hidden email]> wrote:

> you may be able to achieve what you want with two network connectors. one
> to the primary and one to the backup. When both are alive and you use
> decreaseNetworkConsumerPriority and priority dispatch, messages should take
> the shortest path (priority decreases with number of hops).
>
> On 24 October 2014 21:14, Tim Bain <[hidden email]> wrote:
>
> > Gary,
> >
> > I was able to get failover working between brokers in a network of
> brokers
> > using the maxReconnectAttempts=0 URI option.  However, when I tried
> adding
> > priorityBackup=true, I ran into problems.
> >
> >
> http://activemq.2283324.n4.nabble.com/priorityBackup-not-supported-with-masterslave-td4677626.html#a4677945
> > and https://issues.apache.org/jira/browse/AMQ-4720 indicate that
> > priorityBackup won't work with broker-to-broker failover connections, for
> > the same reasons you and I went through last month.
> >
> > For us, this makes failover networkConnectors (including ones using the
> > masterslave transport, since it's just chrome on top of failover)
> useless,
> > since our goal is to minimize the number of hops a message has to take
> and
> > the lack of fail-back behavior on the broker-to-broker connections
> > introduces an extra hop when messages continue going to the backup and
> then
> > have to be forwarded to the primary where all the clients now are.  For
> us,
> > a static mesh is better than a failover network that will have this
> > sub-optimal routing, so we'll stay with that until the static transport
> is
> > able to handle failover transports with the priorityBackup option
> enabled.
> >
> > I looked in JIRA and couldn't find any enhancement request for making the
> > static transport handle this gracefully (your comments on
> > https://issues.apache.org/jira/browse/AMQ-4720 do indicate that that's
> > what
> > would need to happen to fix that bug, but I think it's better as a
> > stand-alone request), so I submitted
> > https://issues.apache.org/jira/browse/AMQ-5411 to capture it.
> >
> > But I think there's also a workaround that could be implemented: if
> > maxReconnects=0, when the priority connection is established following a
> > failover, the failover transport can kill both connections (the old one
> to
> > the backup broker and the new one to the priority broker), let the
> failure
> > bubble up to the static transport, and let it use the failover transport
> to
> > reconnect (to the priority URI, since it's now up).  I've submitted
> > https://issues.apache.org/jira/browse/AMQ-5412 to capture that
> workaround
> > request, in case doing the full rewrite described in AMQ-5411 isn't an
> > option in the near term.
> >
> > Tim
> >
> > On Mon, Sep 29, 2014 at 9:51 AM, Tim Bain <[hidden email]> wrote:
> >
> > > Sounds good; thanks for the explanation.
> > >
> > > On Mon, Sep 29, 2014 at 4:17 AM, Gary Tully <[hidden email]>
> > wrote:
> > >
> > >> everything is possible! but they evolved independently, hence the
> > overlap
> > >> in functionality
> > >>
> > >> On 26 September 2014 16:02, Tim Bain <[hidden email]> wrote:
> > >>
> > >> > Would it be possible for the failover transport to use the same
> > >> > DiscoveryListener mechanism that the static transport uses, but
> that's
> > >> just
> > >> > not how it's been implemented?  Or is there something fundamental
> > about
> > >> why
> > >> > static is allowed to do its own reconnections (notifying the bridge
> > via
> > >> the
> > >> > event handlers on the bridge's DiscoveryListener interface) but
> > failover
> > >> > has to let connection failures bubble up to the bridge?
> > >> >
> > >> > Thanks for taking the time to clarify this, by the way.
> > >> >
> > >> > On Fri, Sep 26, 2014 at 4:14 AM, Gary Tully <[hidden email]>
> > >> wrote:
> > >> >
> > >> > > the failover transport maintains a bunch of state -
> > >> > > connections/sessons/producers/consumers/transactions/messags/acks
> so
> > >> that
> > >> > > it can replay those to maintain and recreate the jms client view.
> > >> > > However, a netwok bridge is not a standard jms client -
> specifically
> > >> in
> > >> > the
> > >> > > duplex case but I think there potential issues in the non duplex
> > case
> > >> > also.
> > >> > > So a failover reconnect will not guarantee that the network bridge
> > is
> > >> > fully
> > >> > > functional. The bridge needs to be stopped and restarted to
> > >> successfully
> > >> > > cleanup and resume.
> > >> > > In other words, the network bridge needs to be aware of transport
> > >> > failures
> > >> > > as they occur. The intent of the failover: transport is to hide
> > those.
> > >> > >
> > >> > >
> > >> > >
> > >> > > On 25 September 2014 19:37, Tim Bain <[hidden email]>
> wrote:
> > >> > >
> > >> > > > Based on the comments that you and Torsten made in the links
> from
> > my
> > >> > > first
> > >> > > > message, I had understood that for networkConnectors between
> > >> brokers,
> > >> > you
> > >> > > > should not allow the discovery transport to perform reconnects,
> > >> because
> > >> > > it
> > >> > > > was important for the network bridge to be notified of the
> > >> > disconnection
> > >> > > > and reconnection.  You said that that happens automatically for
> > >> static
> > >> > > > discovery transports (and I see the onServiceAdd() and
> > >> > onServiceRemove()
> > >> > > > methods in NetworkDiscoveryConnector that would handle those
> > >> events),
> > >> > but
> > >> > > > what's different about failover that makes the same
> > >> DiscoveryListener
> > >> > > > mechanism not work?
> > >> > > >
> > >> > > > On Thu, Sep 25, 2014 at 9:21 AM, Gary Tully <
> [hidden email]
> > >
> > >> > > wrote:
> > >> > > >
> > >> > > > > maxReconnectAttempts=0 relates to the use of failover only,
> > where
> > >> you
> > >> > > use
> > >> > > > > failover to choose between a list of broker urls (typically a
> > pair
> > >> > for
> > >> > > > > master slave). masterSlave sets maxReconnectAttempts=0 on the
> > >> > > underlying
> > >> > > > > failover url.
> > >> > > > > The static discovery, which is implemented by the
> > >> > SimpleDiscoveryAgent
> > >> > > > can
> > >> > > > > do retries and backoff etc.
> > >> > > > > see:
> > >> > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://github.com/apache/activemq/blob/d54e0d6ab590b6a6148a5e2629c45b95d3f40eb8/activemq-client/src/main/java/org/apache/activemq/transport/discovery/simple/SimpleDiscoveryAgent.java#L42
> > >> > > > >
> > >> > > > > The network bridge is a discovery listener, it gets told to
> > >> > add/remove
> > >> > > > > services (urls) that are discovered/retried.
> > >> > > > >
> > >> > > > >
> > >> > > > > On 24 September 2014 20:20, Tim Bain <[hidden email]>
> > >> wrote:
> > >> > > > >
> > >> > > > > > Gary, Torsten, and others have said in various places that
> > >> > > > > broker-to-broker
> > >> > > > > > networkConnectors should set maxReconnectAttempts=0 to allow
> > >> > > > reconnection
> > >> > > > > > to be handled by the network bridge.  (Sources: 1
> > >> > > > > > <
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> http://tmielke.blogspot.com/2011/09/activemq-network-bridge-to-masterslave.html
> > >> > > > > > >,
> > >> > > > > > 2
> > >> > > > > > <
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> http://activemq.2283324.n4.nabble.com/Persistent-messages-disappearing-td4681353.html
> > >> > > > > > >,
> > >> > > > > > 3
> > >> > > > > > <
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> http://grokbase.com/t/activemq/users/1427v9eqkf/prioritybackup-not-supported-with-masterslave
> > >> > > > > > >)
> > >> > > > > > Torsten (link 1) was talking about static: network
> connectors,
> > >> > while
> > >> > > > > Gary's
> > >> > > > > > quotes in the other two links were related to failover: (or
> > >> > > > masterslave:,
> > >> > > > > > which is just chrome on top of failover:), but if it's a
> > >> > requirement
> > >> > > of
> > >> > > > > the
> > >> > > > > > network bridge that it be the one to re-establish the
> > question,
> > >> it
> > >> > > > > > shouldn't matter what the underlying transport is.
> > >> > > > > >
> > >> > > > > > It's obvious in FailoverTransport
> > >> > > > > > <
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-client/5.10.0/org/apache/activemq/transport/failover/FailoverTransport.java#FailoverTransport
> > >> > > > > > >
> > >> > > > > > how maxReconnectAttempts=0 gets processed to mean "don't try
> > to
> > >> > > > > reconnect",
> > >> > > > > > allowing the network bridge to re-establish the connection,
> > and
> > >> > there
> > >> > > > are
> > >> > > > > > notes in
> > >> > > http://activemq.apache.org/failover-transport-reference.html
> > >> > > > > > explaining that this interpretation of the value "0" was
> > >> > implemented
> > >> > > in
> > >> > > > > > 5.6.0 (https://issues.apache.org/jira/browse/AMQ-3542).
> > >> There's
> > >> > no
> > >> > > > > > similar
> > >> > > > > > code in SimpleDiscoveryAgent
> > >> > > > > > <
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-all/5.10.0/org/apache/activemq/transport/discovery/simple/SimpleDiscoveryAgent.java#SimpleDiscoveryAgent
> > >> > > > > > >
> > >> > > > > > (which handles connection attempts for the static: transport
> > >> > > > > > <http://activemq.apache.org/static-transport-reference.html
> >,
> > >> as I
> > >> > > > > > understand it) to interpret "-1" as "reconnect forever" and
> > "0"
> > >> as
> > >> > > > "don't
> > >> > > > > > reconnect".
> > >> > > > > >
> > >> > > > > > Is Gary's and Torsten's advice about maxReconnectAttempts
> not
> > >> > > > applicable
> > >> > > > > to
> > >> > > > > > static: network connectors for some reason that I'm not
> > >> > > understanding?
> > >> > > > > Or
> > >> > > > > > should the changes Gary made in AMQ-3542 have been applied
> to
> > >> all
> > >> > > > > protocols
> > >> > > > > > that include reconnection attempts?  (Do I need to open a
> JIRA
> > >> for
> > >> > > > this?)
> > >> > > > > >
> > >> > > > > > And a related question: when using the static: transport to
> > >> > > establish a
> > >> > > > > > broker mesh, if we set maxReconnectAttempts=0, is there a
> way
> > to
> > >> > > > perform
> > >> > > > > > exponential backoff at the network bridge, so it doesn't
> > >> > continually
> > >> > > > try
> > >> > > > > to
> > >> > > > > > reconnect (and spam the logs) when one broker in the mesh is
> > >> > offline
> > >> > > > for
> > >> > > > > a
> > >> > > > > > while?  The only way I see to control exponential backoff is
> > >> within
> > >> > > the
> > >> > > > > > static: transport via the useExponentialBackOff=true option;
> > >> > > searching
> > >> > > > > the
> > >> > > > > > source code (I'm looking at 5.8.0), I don't see any
> references
> > >> to
> > >> > > > > > exponential backoff in any code that seems to be related to
> > >> network
> > >> > > > > > bridges...
> > >> > > > > >
> > >> > > > > > Thanks,
> > >> > > > > > Tim
> > >> > > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > > --
> > >> > > > > http://redhat.com
> > >> > > > > http://blog.garytully.com
> > >> > > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > --
> > >> > > http://redhat.com
> > >> > > http://blog.garytully.com
> > >> > >
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> http://redhat.com
> > >> http://blog.garytully.com
> > >>
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Static: network connectors and maxReconnectAttempts

gtully
In this case static: will do what you want.

On 30 October 2014 16:52, Tim Bain <[hidden email]> wrote:

> What you're suggesting sounds like it would behave the same as if I use the
> static: transport with two nested URIs, except that I'd have more
> configuration boilerplate since I'd have an additional networkConnector on
> which I'd have to set all of my config options.  Do I get something from
> using the two networkConnectors that I don't get from using a static:
> transport with two nested URIs?  If not, I'll stay with the simpler config,
> until priorityBackup works with networkConnectors.
>
> On Thu, Oct 30, 2014 at 5:53 AM, Gary Tully <[hidden email]> wrote:
>
> > you may be able to achieve what you want with two network connectors. one
> > to the primary and one to the backup. When both are alive and you use
> > decreaseNetworkConsumerPriority and priority dispatch, messages should
> take
> > the shortest path (priority decreases with number of hops).
> >
> > On 24 October 2014 21:14, Tim Bain <[hidden email]> wrote:
> >
> > > Gary,
> > >
> > > I was able to get failover working between brokers in a network of
> > brokers
> > > using the maxReconnectAttempts=0 URI option.  However, when I tried
> > adding
> > > priorityBackup=true, I ran into problems.
> > >
> > >
> >
> http://activemq.2283324.n4.nabble.com/priorityBackup-not-supported-with-masterslave-td4677626.html#a4677945
> > > and https://issues.apache.org/jira/browse/AMQ-4720 indicate that
> > > priorityBackup won't work with broker-to-broker failover connections,
> for
> > > the same reasons you and I went through last month.
> > >
> > > For us, this makes failover networkConnectors (including ones using the
> > > masterslave transport, since it's just chrome on top of failover)
> > useless,
> > > since our goal is to minimize the number of hops a message has to take
> > and
> > > the lack of fail-back behavior on the broker-to-broker connections
> > > introduces an extra hop when messages continue going to the backup and
> > then
> > > have to be forwarded to the primary where all the clients now are.  For
> > us,
> > > a static mesh is better than a failover network that will have this
> > > sub-optimal routing, so we'll stay with that until the static transport
> > is
> > > able to handle failover transports with the priorityBackup option
> > enabled.
> > >
> > > I looked in JIRA and couldn't find any enhancement request for making
> the
> > > static transport handle this gracefully (your comments on
> > > https://issues.apache.org/jira/browse/AMQ-4720 do indicate that that's
> > > what
> > > would need to happen to fix that bug, but I think it's better as a
> > > stand-alone request), so I submitted
> > > https://issues.apache.org/jira/browse/AMQ-5411 to capture it.
> > >
> > > But I think there's also a workaround that could be implemented: if
> > > maxReconnects=0, when the priority connection is established following
> a
> > > failover, the failover transport can kill both connections (the old one
> > to
> > > the backup broker and the new one to the priority broker), let the
> > failure
> > > bubble up to the static transport, and let it use the failover
> transport
> > to
> > > reconnect (to the priority URI, since it's now up).  I've submitted
> > > https://issues.apache.org/jira/browse/AMQ-5412 to capture that
> > workaround
> > > request, in case doing the full rewrite described in AMQ-5411 isn't an
> > > option in the near term.
> > >
> > > Tim
> > >
> > > On Mon, Sep 29, 2014 at 9:51 AM, Tim Bain <[hidden email]>
> wrote:
> > >
> > > > Sounds good; thanks for the explanation.
> > > >
> > > > On Mon, Sep 29, 2014 at 4:17 AM, Gary Tully <[hidden email]>
> > > wrote:
> > > >
> > > >> everything is possible! but they evolved independently, hence the
> > > overlap
> > > >> in functionality
> > > >>
> > > >> On 26 September 2014 16:02, Tim Bain <[hidden email]> wrote:
> > > >>
> > > >> > Would it be possible for the failover transport to use the same
> > > >> > DiscoveryListener mechanism that the static transport uses, but
> > that's
> > > >> just
> > > >> > not how it's been implemented?  Or is there something fundamental
> > > about
> > > >> why
> > > >> > static is allowed to do its own reconnections (notifying the
> bridge
> > > via
> > > >> the
> > > >> > event handlers on the bridge's DiscoveryListener interface) but
> > > failover
> > > >> > has to let connection failures bubble up to the bridge?
> > > >> >
> > > >> > Thanks for taking the time to clarify this, by the way.
> > > >> >
> > > >> > On Fri, Sep 26, 2014 at 4:14 AM, Gary Tully <[hidden email]
> >
> > > >> wrote:
> > > >> >
> > > >> > > the failover transport maintains a bunch of state -
> > > >> > >
> connections/sessons/producers/consumers/transactions/messags/acks
> > so
> > > >> that
> > > >> > > it can replay those to maintain and recreate the jms client
> view.
> > > >> > > However, a netwok bridge is not a standard jms client -
> > specifically
> > > >> in
> > > >> > the
> > > >> > > duplex case but I think there potential issues in the non duplex
> > > case
> > > >> > also.
> > > >> > > So a failover reconnect will not guarantee that the network
> bridge
> > > is
> > > >> > fully
> > > >> > > functional. The bridge needs to be stopped and restarted to
> > > >> successfully
> > > >> > > cleanup and resume.
> > > >> > > In other words, the network bridge needs to be aware of
> transport
> > > >> > failures
> > > >> > > as they occur. The intent of the failover: transport is to hide
> > > those.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > On 25 September 2014 19:37, Tim Bain <[hidden email]>
> > wrote:
> > > >> > >
> > > >> > > > Based on the comments that you and Torsten made in the links
> > from
> > > my
> > > >> > > first
> > > >> > > > message, I had understood that for networkConnectors between
> > > >> brokers,
> > > >> > you
> > > >> > > > should not allow the discovery transport to perform
> reconnects,
> > > >> because
> > > >> > > it
> > > >> > > > was important for the network bridge to be notified of the
> > > >> > disconnection
> > > >> > > > and reconnection.  You said that that happens automatically
> for
> > > >> static
> > > >> > > > discovery transports (and I see the onServiceAdd() and
> > > >> > onServiceRemove()
> > > >> > > > methods in NetworkDiscoveryConnector that would handle those
> > > >> events),
> > > >> > but
> > > >> > > > what's different about failover that makes the same
> > > >> DiscoveryListener
> > > >> > > > mechanism not work?
> > > >> > > >
> > > >> > > > On Thu, Sep 25, 2014 at 9:21 AM, Gary Tully <
> > [hidden email]
> > > >
> > > >> > > wrote:
> > > >> > > >
> > > >> > > > > maxReconnectAttempts=0 relates to the use of failover only,
> > > where
> > > >> you
> > > >> > > use
> > > >> > > > > failover to choose between a list of broker urls (typically
> a
> > > pair
> > > >> > for
> > > >> > > > > master slave). masterSlave sets maxReconnectAttempts=0 on
> the
> > > >> > > underlying
> > > >> > > > > failover url.
> > > >> > > > > The static discovery, which is implemented by the
> > > >> > SimpleDiscoveryAgent
> > > >> > > > can
> > > >> > > > > do retries and backoff etc.
> > > >> > > > > see:
> > > >> > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://github.com/apache/activemq/blob/d54e0d6ab590b6a6148a5e2629c45b95d3f40eb8/activemq-client/src/main/java/org/apache/activemq/transport/discovery/simple/SimpleDiscoveryAgent.java#L42
> > > >> > > > >
> > > >> > > > > The network bridge is a discovery listener, it gets told to
> > > >> > add/remove
> > > >> > > > > services (urls) that are discovered/retried.
> > > >> > > > >
> > > >> > > > >
> > > >> > > > > On 24 September 2014 20:20, Tim Bain <[hidden email]
> >
> > > >> wrote:
> > > >> > > > >
> > > >> > > > > > Gary, Torsten, and others have said in various places that
> > > >> > > > > broker-to-broker
> > > >> > > > > > networkConnectors should set maxReconnectAttempts=0 to
> allow
> > > >> > > > reconnection
> > > >> > > > > > to be handled by the network bridge.  (Sources: 1
> > > >> > > > > > <
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> http://tmielke.blogspot.com/2011/09/activemq-network-bridge-to-masterslave.html
> > > >> > > > > > >,
> > > >> > > > > > 2
> > > >> > > > > > <
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> http://activemq.2283324.n4.nabble.com/Persistent-messages-disappearing-td4681353.html
> > > >> > > > > > >,
> > > >> > > > > > 3
> > > >> > > > > > <
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> http://grokbase.com/t/activemq/users/1427v9eqkf/prioritybackup-not-supported-with-masterslave
> > > >> > > > > > >)
> > > >> > > > > > Torsten (link 1) was talking about static: network
> > connectors,
> > > >> > while
> > > >> > > > > Gary's
> > > >> > > > > > quotes in the other two links were related to failover:
> (or
> > > >> > > > masterslave:,
> > > >> > > > > > which is just chrome on top of failover:), but if it's a
> > > >> > requirement
> > > >> > > of
> > > >> > > > > the
> > > >> > > > > > network bridge that it be the one to re-establish the
> > > question,
> > > >> it
> > > >> > > > > > shouldn't matter what the underlying transport is.
> > > >> > > > > >
> > > >> > > > > > It's obvious in FailoverTransport
> > > >> > > > > > <
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-client/5.10.0/org/apache/activemq/transport/failover/FailoverTransport.java#FailoverTransport
> > > >> > > > > > >
> > > >> > > > > > how maxReconnectAttempts=0 gets processed to mean "don't
> try
> > > to
> > > >> > > > > reconnect",
> > > >> > > > > > allowing the network bridge to re-establish the
> connection,
> > > and
> > > >> > there
> > > >> > > > are
> > > >> > > > > > notes in
> > > >> > > http://activemq.apache.org/failover-transport-reference.html
> > > >> > > > > > explaining that this interpretation of the value "0" was
> > > >> > implemented
> > > >> > > in
> > > >> > > > > > 5.6.0 (https://issues.apache.org/jira/browse/AMQ-3542).
> > > >> There's
> > > >> > no
> > > >> > > > > > similar
> > > >> > > > > > code in SimpleDiscoveryAgent
> > > >> > > > > > <
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-all/5.10.0/org/apache/activemq/transport/discovery/simple/SimpleDiscoveryAgent.java#SimpleDiscoveryAgent
> > > >> > > > > > >
> > > >> > > > > > (which handles connection attempts for the static:
> transport
> > > >> > > > > > <
> http://activemq.apache.org/static-transport-reference.html
> > >,
> > > >> as I
> > > >> > > > > > understand it) to interpret "-1" as "reconnect forever"
> and
> > > "0"
> > > >> as
> > > >> > > > "don't
> > > >> > > > > > reconnect".
> > > >> > > > > >
> > > >> > > > > > Is Gary's and Torsten's advice about maxReconnectAttempts
> > not
> > > >> > > > applicable
> > > >> > > > > to
> > > >> > > > > > static: network connectors for some reason that I'm not
> > > >> > > understanding?
> > > >> > > > > Or
> > > >> > > > > > should the changes Gary made in AMQ-3542 have been applied
> > to
> > > >> all
> > > >> > > > > protocols
> > > >> > > > > > that include reconnection attempts?  (Do I need to open a
> > JIRA
> > > >> for
> > > >> > > > this?)
> > > >> > > > > >
> > > >> > > > > > And a related question: when using the static: transport
> to
> > > >> > > establish a
> > > >> > > > > > broker mesh, if we set maxReconnectAttempts=0, is there a
> > way
> > > to
> > > >> > > > perform
> > > >> > > > > > exponential backoff at the network bridge, so it doesn't
> > > >> > continually
> > > >> > > > try
> > > >> > > > > to
> > > >> > > > > > reconnect (and spam the logs) when one broker in the mesh
> is
> > > >> > offline
> > > >> > > > for
> > > >> > > > > a
> > > >> > > > > > while?  The only way I see to control exponential backoff
> is
> > > >> within
> > > >> > > the
> > > >> > > > > > static: transport via the useExponentialBackOff=true
> option;
> > > >> > > searching
> > > >> > > > > the
> > > >> > > > > > source code (I'm looking at 5.8.0), I don't see any
> > references
> > > >> to
> > > >> > > > > > exponential backoff in any code that seems to be related
> to
> > > >> network
> > > >> > > > > > bridges...
> > > >> > > > > >
> > > >> > > > > > Thanks,
> > > >> > > > > > Tim
> > > >> > > > > >
> > > >> > > > >
> > > >> > > > >
> > > >> > > > >
> > > >> > > > > --
> > > >> > > > > http://redhat.com
> > > >> > > > > http://blog.garytully.com
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > --
> > > >> > > http://redhat.com
> > > >> > > http://blog.garytully.com
> > > >> > >
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> http://redhat.com
> > > >> http://blog.garytully.com
> > > >>
> > > >
> > > >
> > >
> >
>