Thank you for the replies! I'll probably end up creating a wrapper library to address this. Not very clean with the boost object wrapper behavior, but I'm not willing to write my own client at this time, so not much of an alternative. (I don't like the deeper code structure, its a pain to hack anything that needlessly complex.)
Irregardless of how it is accomplished, more control is needed over failover to prevent network splits. The current model is essentially to accept the broker as a single point of failure, or deploy Linux clustering. I'd recommend an ordered broker list with monitoring and automatic fallback, subject to some flap mitigation rules. I also would expose more client state, I understand the desire to hide stuff so people don't use unsupported interfaces, but it is useful for serviceability and diagnostics to have a library expose basic health information. Out of honest curiosity, why don't you like callbacks? We've had to use threading with spin loops to get around the lack of callbacks for the messaging APIs, and we don't like having CPUs loads float high under low load even if the spin loop load drops gracefully under pressure, it feels inelegant and it raises power consumption. Personally, I like callbacks as long as threading models are clearly documented so its understood what can and can't be done safely, especially in conjunction with a decent sig/slot library to decouple threading models of subsystems. I've built servers that handle nearly 100k active sessions (video games) this way, FWIW... It would be nice if the Apache QPID team gave a little more support to Windows. No (official) Windows service, still no broker federation / clustering. Kerry Bonin On Tue, Jun 28, 2011 at 7:52 AM, Gordon Sim <[email protected]> wrote: > On 06/27/2011 08:19 PM, Kerry Bonin wrote: > >> I was wondering if there was any existing way to know when a broker >> failover >> occurs (and which broker is active), other then hacking the client? >> > > In a clustered broker you can get notifications of changes to cluster > membership. However other than that the c++ client library doesn't have any > callbacks to notify of automatic reconnection attempts or to determine where > a connection is connected to at any point in time (assuming it is > connected). > > I don't like callbacks, at least at this level of the API, but I would > agree that these would be nice concerns to address. Having some way to get > some form of peer address would be nice, as would a way to be notified of > disconnect and reconnect events. > > (Apologies for the delayed response on user thread btw) > > > > ------------------------------**------------------------------**--------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: > mailto:dev-subscribe@qpid.**apache.org<[email protected]> > >
