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

[Darien Kindlund]

Hi Ben,

Just my $0.02, but, I got the impression a (durable=True,
auto_delete=True) use case means: "Delete the queue ONLY after all
messages have been removed from the queue -- once the queue is empty."

A condition where this would apply is: Consider a producer/consumer
scenario.  The consumer creates a static exchange/queue (durable=True,
auto_delete=False) such that in the event of a network error, the
consumer can reconnect and resync with the queue.  Upon receipt of a
new message, the consumer sends an ACK message (part of the
application -- not the AMQP spec) back to the producer (using the
reply-to: header).

The producer creates a temporary exchange/queue (durable=True,
auto_delete=True) for receiving these ACK messages such that in the
event of a network error, the producer can reconnect and resync with
the queue.  From the producer's point of view, it wants a queue that
*remains alive until all messages have been flushed* from the queue.
In this case, lost messages are not acceptable.

A downside to this approach (obviously) are cases where logic errors
in the producer cause the producing app to die, which becomes a more
common problem than network errors.  In this case, RabbitMQ ends up
with a bunch of temporary producer queues with (maybe) one or 1 ACK
messages in each queue, that stick around forever.  In this case,
you'd have to write some sort of utility script to purge the
no-longer-used queues.

Therefore, (durable=True, auto_delete=True) comes in handy in cases
where the producing app:

1) has no logic errors (that cause it to disconnect without emptying its queue)
2) is talking across a network that is prone to channel disconnects

A couple of side notes:
- In this scenario, it maybe possible to 'timeout' a (durable=True,
auto_delete=True) queue, where if it has messages and has no
consumers, wait X minutes before deleting (configurable).

- If (durable=True, auto_delete=True) becomes an invalid configuration
in the next version of the AMQP specification, then the producing app
would have to contain application-level logic to deal with network
disconnects (rather than rely on AMQP to do the right thing).  Or, it
would have to switch to declaring a static queue and not rely on the
auto_delete option.

Regards,
-- Darien

On Fri, Jan 23, 2009 at 6:02 AM, Ben Hood <0x6e6562 at gmail.com> wrote:
> 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
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>