[rabbitmq-discuss] Read now ack later, much later -- maybe after program restart

[Matthew Sackman]

On Fri, Jul 22, 2011 at 12:10:13PM -0400, Lowell.Boggs at emc.com wrote:
> What happens to messages in durable queues which have already been _read_ but which have not yet been _acked_ when:
> 
> 1.  rabbit is shutdown gracefully?

They are requeued to the back of the queue.

> 2.  the consumer channel closes abruptly -- say from crash, kill, or forced shutdown?

They are requeued to the back of the queue.

This is only relevant for persistent messages - transient messages will
be lost if rabbit dies in any way.

The one exception to the requeuing at the back rule is if rabbit is hard
killed. There's a possibility that the fact that the message has been
delivered to a consumer has not been successfully recorded on disk. As
such, on recovery, the message may reappear at the front of the queue,
rather than the back.

> The rabbitmq documentation gives me the impression that I can read
> messages from a durable queue and choose not to ack them until I  want
> -- perhaps hours later.  Obviously, I have to watch my queue sizes in
> this situation.  But what happens if the application never acks the
> messages before it terminates?  What will happen when the
> rabbitmq-server is restarted or when or the program is restarted, will
> it get the messages again?

They are requeued to the back of the queue.

> Suppose I have multiple consumers reading from the same durable queue
> in a round robin fashion (read ahead is 1) and one consumer has read
> but not acked 10 messages.

Not possible. If qos prefetch is 1 then that consumer will be sent at
most 1 message at a time and will then receive no more until it acks
that message.

>  If it dies, or at least closes the
> connection abruptly, will those 10 messages be sent to the other
> consumers to read?

Yes.

Matthew