You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Jiri Krutil <ji...@krutil.com> on 2011/08/15 15:56:39 UTC
Detecting lost connection on a C++ Receiver
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.
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.
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?
Cheers
Jiri
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Detecting lost connection on a C++ Receiver
Posted by Gordon Sim <gs...@redhat.com>.
On 08/15/2011 04:14 PM, Jiri Krutil wrote:
> We're using qpid-cpp-client-0.7 (sorry for the wrong info in the
> original post).
>
> I have a Receiver for an empty exclusive auto-delete queue. If I call
> get() with Duration IMMEDIATE on this Receiver after the broker was
> stopped, it still returns false instead of throwing.
That is, I believe, fixed from 0.10 onwards.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Detecting lost connection on a C++ Receiver
Posted by Jiri Krutil <ji...@krutil.com>.
> When you say 'stop the broker' do you mean send a STOP signal, or
> shut it down?
I'm stopping the broker using "qpidd -q".
> 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.
We're using qpid-cpp-client-0.7 (sorry for the wrong info in the
original post).
I have a Receiver for an empty exclusive auto-delete queue. If I call
get() with Duration IMMEDIATE on this Receiver after the broker was
stopped, it still returns false instead of throwing.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Detecting lost connection on a C++ Receiver
Posted by Kerry Bonin <ke...@gmail.com>.
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 <gs...@redhat.com>
> 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<us...@qpid.apache.org>
>
>
Re: Detecting lost connection on a C++ Receiver
Posted by Gordon Sim <gs...@redhat.com>.
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