everything is possible! but they evolved independently, hence the overlap in functionality
On 26 September 2014 16:02, Tim Bain <tb...@alumni.duke.edu> 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 <gary.tu...@gmail.com> 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 <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 > > > -- http://redhat.com http://blog.garytully.com
