Actually, using an explicit call to Session::hasError() is the only way I've found to expose some client library state data. I wish the library had callbacks for message receipt and state changes (broker connection lost, broker failover to <>), coupled with a nice signal-slot library we could simplify our threading model.
I'm getting to burn a good deal of time building a wrapper over qpid client to overcome broker reliability issues. Without clustering or federation on Windows, and without a deterministic way to control failover fallback, we routinely see network splits in our tests when one set of clients is talking to the broker they failed over to, and another set of clients is talking to the initial broker once it came back online. We are having to add code to track connections to all brokers in our failover list and manually manage failover to guarantee that failover recovery occurs properly to avoid splits. We know of no method other than polling hasError in our message rx spin loops to see if a broker is down (other than pinging a queue on that broker and looking for an exception.) If there is a better way to determine broker health and control failover in the C++ client I'd love to know about it. 2011/8/15 Gordon Sim <[email protected]> > On 08/15/2011 02:56 PM, Jiri Krutil wrote: > >> Hi >> >> I'm using the Qpid messaging C++ client v0.8 to receive messages with >> the auto-reconnect disabled. >> >> I'm testing what happens with my receiving client app when I stop the >> broker. >> > > When you say 'stop the broker' do you mean send a STOP signal, or shut it > down? > > > Even if the client lib prints a warning about the connection being >> closed, the Receiver functions still seem to work as if nothing had >> happened - for instance getAvailable() or get() return normally. >> > > What version are you using and can you provide a reproducer? I see an > exception being thrown if get() is called and the connection has been lost. > > > I find this a bit misleading - it looks like the Receiver is just >> waiting for messages, but actually it has no connection and therefre the >> messages will never appear. >> >> It seems that calling Session::hasError() can be used to detect a dead >> connection, but I have to call this explicitly every time the Receiver >> tells me that it has no messages ready (kind of paranoid approach). >> >> It appears the client lib "knows" the connection was lost, but somehow >> it does not communicate it to the Receiver. >> >> Is there some (efficient) way how to check if a Receiver is alive? >> >> How expensive is Session::hasError()? Does it require a broker roundtrip? >> > > No, it doesn't require a round trip. It just checks local state. It is not > expensive, but I wouldn't expect you to have to call it explicitly. > > > ------------------------------**------------------------------**--------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: > mailto:users-subscribe@qpid.**apache.org<[email protected]> > >
