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.
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-subscr...@qpid.apache.org
