For the java client the simplest solution I could think of is to use a static list of brokers in the connection URL. The JMS client will then try them in a round robin fashion if the broker it's currently connected to fails. The JMS client will only throw a connection exception if all the brokers are down. So the failover is transparent to the client.
You could perhaps do the same for your python and C++ clients. I think the new python API may have a similar feature already. Rafi is the best person to ask about it. Rajith On Wed, May 5, 2010 at 2:39 PM, Alan Conway <[email protected]> wrote: > On 05/05/2010 02:04 PM, Kerry Bonin wrote: >> >> I've been walking down a rat hole and thought I'd take a moment to ask >> the list how I should proceed - I could use some advice from someone >> with deeper QPID experience... >> >> My requirement is relatively simple - I've got a number of clients >> using QPID , all currently Windows platforms, with clients in C++, >> Python, and Java. We need the system to handle broker process / host >> failure, preferably in a manner transparent to the client applications >> (although we can insert code between the client applications and the >> QPID client library.) >> >> We can run multiple brokers, and had planned on deploying a broker on >> each server box, and wanted at least some sort of failover solution. >> Our problem - how to proceed on Windows? >> >> QPID Clustering is built over Corosync, which I believe limits it to a >> subset of *nix platforms. >> >> Federation with failover would work, but Federation doesn't work on >> Windows. (I'm still looking at QPID-2199...) >> >> Failover code in progress appears tied to clustering, which is out for >> Windows. >> >> Should I just roll my own standalone failover, forking if necessary to >> expose lower features? (I don't want to do this!) Can I leverage the >> Failover code in the trunk and manage amq.failover without the >> Corosync dependent code? Are there any simpler approaches I'm >> missing? >> >> Comments greatly appreciated... >> > > The client side of failover doesn't involve corosync at all. Clients > subscribe to the amq.failover exchange to get updates on the list of brokers > they can use for failover, and if they detect a connection failure they > iterate over this list till they get a connection. All this is standard > AMQP. > > The cluster plugin on the broker generates those updates based on corosync > membership changes. If you had an alternate plugin generating membership > updates then it could drive the existing client failover with no changes on > the client. Of course this assumes some non-corosync source for the > membership info but you'd need that anyway in a roll-your-own scheme. > > I'd be happy to help out if you're interested in implementing something like > this. Generalizing the failover-list notification scheme is preferable to > forking and I think will be useful in other contexts as well. > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
