RabbitMQ difference between exclusive and auto-delete?

user782220 picture user782220 · Jan 21, 2014 · Viewed 39.2k times · Source

The "RabbitMQ in Action" book on page 19 gives these descriptions of exclusive and auto-delete:

exclusive - When set to true, your queue becomes private and can only be consumed by your app. This is useful when you need to limit a queue to only one consumer.

auto-delete - The queue is automatically deleted when the last consumer unsubscribes. If you need a temporary queue used only by one consumer, combine auto-delete with exclusive. When the consumer disconnects, the queue will be removed.

But as far as I can see when using exclusive, auto-delete is redundant. Only exclusive is needed. The RabbitMQ tutorial seems to say that is the case

...once we disconnect the consumer the queue should be deleted. There's an exclusive flag for that:

result = channel.queue_declare(exclusive=True)

There is no mention in that tutorial about auto-delete and sudo rabbitmqctl list_bindings seems to indicate that the queue is in fact deleted after the receiver goes away.

Answer

theMayer picture theMayer · Jan 21, 2014

Well, it is true that exclusive queues will auto-delete when the consumer disconnects (see the documentation pasted below). However, there are cases when you want queues to be non-exclusive, yet still auto-delete (for example, if I want to add another consumer).

exclusive

Exclusive queues may only be accessed by the current connection, and are deleted when that connection closes. Passive declaration of an exclusive queue by other connections are not allowed.

auto-delete

If set, the queue is deleted when all consumers have finished using it. The last consumer can be cancelled either explicitly or because its channel is closed. If there was no consumer ever on the queue, it won't be deleted. Applications can explicitly delete auto-delete queues using the Delete method as normal.

Personally, I prefer to use neither of these parameters, instead opting for the RabbitMQ queue expiration parameter, which is better if I have a consumer disconnect and then re-connect immediately (or a short time) later; messages are not lost in this case. But, of course it all depends upon your application and requirements.