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 <tb...@alumni.duke.edu> 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 <gary.tu...@gmail.com> 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 <tb...@alumni.duke.edu> 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
