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

[Bell, Paul M.]

Thank you, Simon.

-Paul

-----Original Message-----
From: rabbitmq-discuss-bounces at lists.rabbitmq.com [mailto:rabbitmq-discuss-bounces at lists.rabbitmq.com] On Behalf Of Simon MacMullen
Sent: Wednesday, January 25, 2012 9:21 AM
To: rabbitmq-discuss at lists.rabbitmq.com
Subject: Re: [rabbitmq-discuss] Lack of Ack, Failure and Re-delivery

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
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss at lists.rabbitmq.com
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss



ATTENTION: -----

The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other  confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control.