[rabbitmq-discuss] Is there a use case for a queue with auto_delete=True and durable=True?

[Ben Hood]

Brian,

Just posting this back via the mailing list because you did not choose
LShift's $10000 per question option ;-)

On Fri, Jan 23, 2009 at 9:05 AM, Ben Hood <ben at lshift.net> wrote:
> ----- Forwarded message from Brian Sullivan <bsullivan at lindenlab.com> -----
> I was just explaining scenarios for the various persistence settings, and
> couldn't come up with a use case for creating an auto-delete queue (which
> is the default), but setting durable = true.

Have you read what the 0.8/0.9.1 spec says on what effect each flag
has for the queue.declare command?

Though the spec does not specify default values, our internally
generated commands use a JSON version of the actual specification that
has been augmented with Rabbit considers to be *sensible* default
values.

In the file amqp-0.8.json the auto_delete flag on queue.declare is off.

The relevance of this is marginal because it is up to what the client
library actually puts on the wire.

> Upon restart after a server
> crash, I'd assume that the client would take a little bit of time to
> reconnect, in which case the queue would be deleted, even if it was
> durable, correct?

The events that trigger a consideration of the auto_delete flag in
Rabbit are subscription cancellations and the channel going down.

> Is there a use case for this combination of settings?  I have seen some
> posts that have been confused by not having queues remain when
> durable=true if people forget to set auto-delete=false, so it seems odd to
> have the defaults set the way they are (at least as they appear to be in
> the python lib)

I would consider it to be odd, but I'm not a lawyer.

Though the exact behavior of this scenario is IMHO not clearly defined
in the spec, I think that most implementations would take a common
sense approach.

>From the perspective of py-amqplib, I would say that it's over to
Barry to make a call on this.

BTW, feel free to question any spec related aspect of AMQP, we'll do
our best to try an explain why it is like it is, although we didn't
write it.

HTH,

Ben