Arnaud, That is a bug as the failover should reset itself each time a connection is made. It would be nice though at some point to separate retry strategy from failover, but that is potentially a much larger piece of work.
Cheers Martin 2009/3/3 Rajith Attapattu <[email protected]>: > I too agree with Arnaud. > By default it makes sense to keep retrying the list of brokers until > all nodes are down. > > Regards, > > Rajith > - Show quoted text - > On Tue, Mar 3, 2009 at 11:17 AM, Arnaud Simon <[email protected]> wrote: >> Hello, >> >> I have been playing with our 0.10 cluster. When testing it I used a java >> client and 2 brokers. I quickly ran into this issue: >> >> org.apache.qpid.transport.ConnectionException: connection closed >> at org.apache.qpid.transport.Connection.send(Connection.java:294) >> at org.apache.qpid.transport.Session.send(Session.java:455) >> at org.apache.qpid.transport.Session.invoke(Session.java:599) >> >> >> It appears that this is an expected behaviour of our default Java failover >> manager. The default heuristic is to go roundrobin through the list of >> brokers. This is fine really but our implementation does not reset the >> cursor position after a successful failover. This means that if you >> failover from A to B you will never failover from B to A anymore (assuming >> that our list of broker only contains two brokers A and B). So, there is >> an optional parameter "cyclecount" that can be used to define the number of >> times to loop through the list of available brokers before failure. If this >> parameter can be used to solve the issue of failing over to A after a >> successful failover from A to B, it does solve this issue only for >> "cyclecount" times :( Moreover, I believe that we don't really want to cycle >> through all the brokers more than once when all the nodes of the broker are >> down. We rather want to define a kind of back-retry mechanism. >> >> I would suggest that default implementation of our roundrobin failover >> manbager should be changed to reset the cursor position within the broker >> list to the current broker. Moreover, I believe that some people are >> currently implementing a failover manager that uses a failover exchange. I >> am wondering whether this manager shouldn't the default manager for our 0.10 >> client? >> >> Please let me know what you think. Should we open a JIRA? >> >> Thanks >> >> Arnaud >> >> >> --------------------------------------------------------------------- >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:[email protected] >> >> > > > > -- > Regards, > > Rajith Attapattu > Red Hat > http://rajith.2rlabs.com/ > - Show quoted text - > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > -- Martin Ritchie --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
