[rabbitmq-discuss] Exclusive queues and delete-on-disconnect
matthias at lshift.net
Wed Jan 20 08:48:18 GMT 2010
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
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.
More information about the rabbitmq-discuss