[rabbitmq-discuss] Exclusive queues and delete-on-disconnect

[Matthias Radestock]

Garrett,

Garrett Smith wrote:
> My understanding is that declaring a queue as exclusive will cause the
> queue to be deleted as soon as the declaring channel (or connection?)
> is closed.

It's the declaring *connection*.

> I've observed cases when a channel/connection has not been closed
> cleanly (e.g. sudden network failure) and the queue is not deleted.

That shouldn't happen, except ... certain types of network failure can 
take a while to be recognised as disconnects by the OS' network stack.

One way to counter that is to enable AMQP heartbeats, which most AMQP 
clients (including all the supported RabbitMQ clients) support. That 
will cause a peer to close the connection when it hasn't received any 
data from the server for the configured heartbeat interval and thus puts 
an application-configured upper bound on the length of time a disconnect 
may go unnoticed.

> When the consumer re-declares (e.g. on restart), the broker complains
> about an exclusive queue already existing. The fix I'm using is to
> manually delete the queue.
> 
> Are there any suggestions for dealing with this?

Even with heartbeats enabled you still essentially have a race since the 
re-declaration may happen before a heartbeat has been missed. When that 
happens, you could pause and re-try, or, as you say, explicitly delete 
the queue.

Or perhaps you could declare anonymous queues, i.e. create a queue with 
a fresh name every time you connect? See also the next point.

> Apart from the added complexity of restarting the consumer, I'm 
> concerned that messages will pile up in the queue with on one to
> consume them.

Unless the network is mis-configured or you are using broken network kit 
then even w/o a heartbeat the broker will eventually recognise the 
disconnect and thus delete the queue. It may take a while - seconds, 
minutes - but it will happen.


Regards,

Matthias.