You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Kerry Bonin <ke...@gmail.com> on 2011/06/24 23:21:38 UTC

Is there a way to monitor and control client broker failover activity?

We are experiences some issues with failover (reports that not all clients
are failing over on primary broker failure), and would like to know if there
is any way from the client library API to know when a failover occurs and to
which broker the failover has occurred?

On a related note, is there any way to tell the client to return to earlier
brokers once they come back online?  Otherwise its possible to have clients
spread across brokers.  This may be fine when federation and/or clustering
is on, but IIRC that still isn't an option for Windows users...

Thanks!

Re: Is there a way to monitor and control client broker failover activity?

Posted by Gordon Sim <gs...@redhat.com>.
On 06/24/2011 10:21 PM, Kerry Bonin wrote:
> We are experiences some issues with failover (reports that not all clients
> are failing over on primary broker failure), and would like to know if there
> is any way from the client library API to know when a failover occurs and to
> which broker the failover has occurred?

No, I'm afraid there is not at present.

> On a related note, is there any way to tell the client to return to earlier
> brokers once they come back online?

No there is not.

> Otherwise its possible to have clients
> spread across brokers.  This may be fine when federation and/or clustering
> is on, but IIRC that still isn't an option for Windows users...

Without some broker-to-broker communication, you could only detect that 
the earlier broker was back online by periodically trying to connect 
from the client process. Once you found it was, you would need to abort 
the connection established to the backup and use the earlier broker (the 
c++ API doesn't have a way of doing that,at present, it just has close()).

I'd suggest in this use case it may be simpler to turn automatic 
reconnect off and handle reconnection yourself. There may be ways in 
which we could enhance the API to make this simpler and I'd be keen to 
hear suggestion on that.


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org