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:[email protected]
