Use the on_transport_closed event to detect a client closing it's TCP
connection. Other closed events (on_link_closed, on_connection_closed) are
generated when the remote end politely closes the AMQP state associated
with link, connection etc. - you will not get these events if there's a
failure and the TCP connection closes abruptly. You will always get an
on_transport_closed event when a client disconnects, either abruptly or
politely.

In the case of a network or host failure the TCP layer may take a long time
to detect the disconnect, so to ensure it is detected within some definite
time you can set the idle_timeout connection option. This has a similar
effect as bouncing messages off the client, but is built into the AMQP
protocol so it is more efficient and requires less coding on your part.

On Sun, Feb 11, 2018 at 4:48 PM, rherbert <nab...@ryan.xar.us> wrote:

> I'm writing a service based on the server.cpp and multithreaded_client.cpp
> examples. I'm maintaining a map of senders to reply to the clients (which
> are using a dynamic queue), but I don't know how to tell when the client
> goes away, so my map just continues to increase in size.
>
> I've tried setting the source_options and target_options on both sides to
> have an expiry_policy of LINK_CLOSE and a timeout of IMMEDIATE, but still I
> don't see anything different.
>
> Is there a way I can do this? Or do I need to bounce a message to the
> client
> every once in a while to see if it's still there?
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-
> f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Reply via email to