[rabbitmq-discuss] durable exclusive queues

Sun Sep 7 04:57:36 BST 2008

Aman,

Aman Gupta wrote:
> According to the spec, a durable queue cannot be exclusive, as exclusive 
> implies auto-delete:
> 
>     request an exclusive queue
>       Exclusive queues may only be consumed from by the current connection.
>       Setting the 'exclusive' flag always implies 'auto-delete'.

IIRC the spec does not prohibit the declaration of durable exclusive 
queues. However, such queues will not survive restarts since they are 
"owned" by the connection that created them - that is the essence of 
exclusivity - and since that connection will get dropped on a restart so 
will the queue. So, in a way, they durable exclusive queues are nonsensical.

> Is it possible to simulate this exclusive behavior?  I can do a passive
> declare and look at the consumer count in the declare-ok, but that will 
> introduce race conditions without a central lock.

It is not clear from the above what exactly you are trying to simulate. 
Durable exclusive queues? As I explained, that doesn't make sense.

 From your description though it appears that perhaps you want queues 
that are exclusive to one connection *at a time*, i.e. they can be 
"acquired" by different connections over their lifetime. And such queues 
could of course then sensibly be made durable.

If so, then one way to implement that is to have a secondary queue that 
holds a token. Connections that want to use the "shared exclusive queue" 
subscribe to the token queue. When they receive the token they know they 
have exclusive access. To relinquish access they publish the token back 
to the token queue, where it can be consumed by another connection.

Obviously that requires collaboration between the connections - it won't 
stop a malicious connection from just accessing the "shared exclusive 
queue" without getting the token first. Also, you may need to find a way 
to recover tokens that are "lost" when a connection gets dropped.

I hope that answers your question. If not, please explain your use case 
in more detail.

Regards,

Matthias.