qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Colby <p...@colby.id.au>
Subject Re: can the C++ broker expire really idle connections?
Date Mon, 22 Aug 2011 09:53:12 GMT
On Mon, Aug 22, 2011 at 6:58 PM, Gordon Sim <gsim@redhat.com> wrote:

> On 08/22/2011 03:08 AM, Paul Colby wrote:
>> Hi,
>> I have a C++ broker (0.10) running, which has messages stuck in a handful
>> of
>> queues.  It seems that these messages are "stuck" because the broker has
>> given them to one of my consumer processes, which has not yet
>> ack'd/rejected/released the messages.  The problem is, the consumer in
>> question died almost 5 days ago!
>> Actually the situation is quite a bit more complex than that...  to
>> explain,
>> my consumer is a C++ client with an embedded PHP engine.  At the time the
>> process died, one of its threads was in the process of writing to a
>> BASH-based sendmail script.  So, although the client itself is gone, the
>> BASH interpreter is still running (sleeping, waiting for more input) and
>> seems to have inherited the Qpid socket fd (perhaps due to the fork / exec
>> process used by PHP's mail function internally).
>> Of course there's plenty I can (and will) do to prevent this situation
>> from
>> occurring on my side.  But it leads me to also wonder, is there a way I
>> can
>> configure the C++ broker to reclaim messages that have not yet been ackd /
>> rejected / released by a consumer that has been idle for a very long time
>> (qpid-tool -c reports these connections as being idle for 4+ days).
>> I see there's a client-side heartbeat connection option... is there
>> something equivalent for the server side?
> If the client requests that heartbeats be used then the server will abort a
> connection if it does not receive two consecutive heartbeats from the client
> (the client does the same w.r.t the server). The broker cannot unilaterally
> turn heartbeats on however.

Okay great! :)

So the client requests / enables heartbeats, but both the client and broker
enforce / require them once enabled.



>  I have a lot of data I can include (such as outputs from qpid-tool showing
>> the connections / sessions etc in question)... perfectly happy to post
>> them
>> if you like :)
>> Thanks!!
>> Paul
>> ----
>> http://colby.id.au
> ------------------------------**------------------------------**---------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.**apache.org<users-subscribe@qpid.apache.org>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message