You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Arnaud Simon <as...@redhat.com> on 2009/03/03 17:17:45 UTC
Java failover manager
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:dev-subscribe@qpid.apache.org
Re: Java failover manager
Posted by Martin Ritchie <ri...@apache.org>.
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 <ra...@gmail.com>:
> 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 <as...@redhat.com> 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:dev-subscribe@qpid.apache.org
>>
>>
>
>
>
> --
> 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:dev-subscribe@qpid.apache.org
>
>
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Java failover manager
Posted by Rajith Attapattu <ra...@gmail.com>.
I too agree with Arnaud.
By default it makes sense to keep retrying the list of brokers until
all nodes are down.
Regards,
Rajith
On Tue, Mar 3, 2009 at 11:17 AM, Arnaud Simon <as...@redhat.com> 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:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Java failover manager
Posted by Carl Trieloff <cc...@redhat.com>.
yes, the defaults don't seem to be the best, I would JIRA it.
Carl.
Arnaud Simon 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:dev-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org