[rabbitmq-discuss] General approaches for tracking unreclaimed memory

[Garrett Smith]

On Tue, Oct 27, 2009 at 8:00 PM, Matthias Radestock <matthias at lshift.net> wrote:

>> So, here's the problem, which everyone reasonably faces: when a
>> consumer goes away, their queues pile up, which is basically a "leak"
>> at the application/system level (not with rabbit).
>>
>> I'm being a little lazy here by not looking into the docs or the AMQP
>> spec, but is there a way to guard against an eventual crash in this
>> case (I believe this has manifested itself for me once by running out
>> of Erlang processes, but memory is certainly an issue as well)?
>
> I'd definitely recommend reading the spec. If you did then you'd know about
> the exclusive and auto-delete flags to queue.declare ;) Queues declared with
> the former get automatically deleted when their creating connection
> disappears, and the latter when their last consumer disappears.

Yup, I'm familiar with those flags (and actually have read the spec, a
few times even :)

I need both non-exclusive/non-auto-delete so that the queue is
preserved when either the creating connection or the last consumer
goes away. Various agents come and go (restarting is one example, but
there are other cases). Not to preach to the choir, but one of the
benefits of async messaging is you can insulate from dropped
connections.

It sounds like I'm left with the option of running a cleanup/check
process occasionally to ensure that we don't run into queues piling
up. No other options, given exclusive=false and autodelete=false?

I know that the expires/TTL is ignored in rabbit, and is perhaps not
entirely fleshed out in the 0.8 spec, but it seems an important
feature wrt resource resource management.

Garrett