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

[Matthias Radestock]

Darien,

Darien Kindlund wrote:
> 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."

How did you get that impression? There is an "if-empty" flag on 
queue.delete, which prevents deletion if the queue contains messages, 
but there is no equivalent behaviour defined for auto_deletion.

As an aside, in AMQP 0-9-1 the rules for exclusive queues have been 
clarified. Exclusive queues get deleted when their creating connection 
closes, regardless of whether the queue ever had any consumers. By 
contrast, auto_deletion takes place when a queue's last consumer is 
removed (either explicitly or as a side-effect of channel/connection 
closure).

> 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.

Since the producer knows how many acks it is waiting for, it can declare 
the queue as durable and non-auto_delete, and delete it explicitly when 
all acks have arrived.


Regards,

Matthias.