[rabbitmq-discuss] Lack of Ack, Failure and Re-delivery

[Simon MacMullen]

On 25/01/12 14:05, Bell, Paul M. wrote:
> Hello again,
>
> I’m working my way through several recovery scenarios. I think we’ve
> established the following:
>
> a.If broker bounces, durable messages in the durable queue that have
> been consumed – but not acked – will be redelivered.
>
> b.Such redelivered messages will have the “redelivered” flag set.
>
> c.If consumer bounces, both (a) and (b) still hold.
>
> In re (a): is redelivery accomplished by placing another copy of the
> message in the queue (thus, two copies of same message are in the  queue
> – one consumed but not acked, the other brand new); OR does the broker
> simply know that it’s OK to redeliver the original message?

The broker just knows it's OK to redeliver the original message.

> In re (b): the redelivered flag seems to enable the creation of what
> Hohpe calls an “idempotent receiver.” That is, the consumer can use this
> flag to decide how to dispose of the redelivered message. Consider a
> scenario wherein the consumers, all pulling from a single queue,
> dispatch the work to a lower layer service. If there are multiple
> consumer nodes (even multiple consumer threads), they will need some
> means of coordinating the disposition of the redelivered message. For
> example, NodeA consumes (but doesn’t ack) message 1. But it does
> dispatch the work represented by message 1 to a lower layer service. If
> the broker bounces and message 1 is redelivered, it might be consumed by
> NodeB. But the message 1 task is already in-flight on NodeA. So,
> depending on both the idempotency of the task and application specific
> functionality, NodeB might want to discard the redelivered message 1.
> Such intra-consumer/intra-consumer node coordination suggests that the
> first consumer of the message needs to record something, probably in the
> persistence layer, that says “I’ve started this particular task (using a
> unique request ID). Does this seem right?

Yes, depending on what exactly your requirements are. The redelivered 
flag is there as an optimisation, so you don't have to check every message.

> In re (c): does redelivery after consumer bounce work because the broker
> detects the loss of connection?

Yes.

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, VMware