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 <gary.tu...@gmail.com> 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 <tb...@alumni.duke.edu> 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 <tb...@alumni.duke.edu> wrote: > > > > > Sounds good; thanks for the explanation. > > > > > > On Mon, Sep 29, 2014 at 4:17 AM, Gary Tully <gary.tu...@gmail.com> > > wrote: > > > > > >> 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 > > >> > > > > > > > > >
