Robert Godfrey wrote:
OK - there are a few more implications to this than is obvious at first
sight...
namely when we create a durable subscription to a topic through JMS we
create the durable queue as "exclusive".
That is we are expecting that only the specified client will be able to
consume from it.
That is not the same as saying that only this "user" should be able to
consume from this queue (which would be an ACL controlled prescription).
Nor is it the same as saying that only the current connection can subscribe
to this queue (which is what the current "exclusive" implies).
I am not sure that exclusive should imply auto-delete... but that exclusive
should in fact be based on "client identity". Therefore if a client is
disconnected for some reason, they can re-connect and pick up where they
left off.
Thoughts?
As well as declaring a queue as 'exclusive' (meaning only to be used by
this connection, and hence implying that the queue is deleted when the
connection is terminated), there is the ability to request exclusive
consumption from a queue (through the exclusive field in basic_consume).
The latter ensures that only the current consumer is receiving messages
from that queue. Perhaps that would be a better way to guarantee
exclusive access to a durable subscription (at least in terms of the
current spec)?
The dual use of the name 'exclusive' confused me in the past as well and
using 'private' for the queue_declare field has been suggested in the
past to try to avoid this.
