[rabbitmq-discuss] auto_delete queues not going away

[Tim Cole]

On Thu, 2009-11-05 at 23:02 +0000, Matthias Radestock wrote:
> Marking an exclusive queue as durable is quite a strange thing to do, 
> since 'exclusive' means the queue should go away when the creating 
> connection dies, such as during a broker restart, but 'durable' means it 
> should survive broker restarts.

The reason for durable in this case was to match the exchange, since a
decision had been made to declare the exchange manually as a once-off
and keep it around rather than having clients do that.  I'm content to
have the clients attempt to declare the exchange if it doesn't exist
though.

> There is in fact a known problem with durable, exclusive queues - if the 
> server restarts it is possible that these queues survive even though 
> their owning connections are dead.

Hm, in this case the server wasn't restarted, but the clients were shut
down and replaced by new machines.  Perhaps it's also an issue if the
connection wasn't shut down cleanly?

> So I suggest dropping the 'durable' flag.
> 
> Also note that auto_delete only kicks in only after the queue has had at 
> least one consumer registered with basic.consume. basic.get doesn't count.

basic.consume was in use in this case.

> And exclusivity is attached to the *connection*, not the channel, so 
> it's worth checking that the connection(s) which created the queues are 
> indeed dead.

They definitely are; the client machines to which those queues belonged
were taken down.

Anyway, it sounds like what we want in this particular case is
durable=False, exclusive=True, and auto_delete=False.  Ideally, we don't
actually want the queue to go away when the channel/consumer dies, but
only if the connection does.  Does that sound right?

Thanks,
-Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20091106/1bd651f9/attachment.pgp