[rabbitmq-discuss] durable exclusive queues
matthias at lshift.net
Sun Sep 7 04:57:36 BST 2008
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.
More information about the rabbitmq-discuss