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]
