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

Sat Jan 21 22:47:44 GMT 2012

By the way, I suggest you to set up some exploratory tests, they are very
useful to figure out how the broker behaves under certain circumstances. In
this case it may not be obvious the order in which unacked messages will be
redelivered. Just recently the behavior of the broker has changed whereby
messages are put at the top of the queue, while it used to be at the end.
On Jan 21, 2012 11:39 PM, "Bell, Paul M." <pbell at syncsort.com> wrote:

> Thank you both.
>
> -Paul
>
> On Jan 21, 2012, at 5:24 PM, "Simone Busoli" <simone.busoli at gmail.com>
> wrote:
>
> Also in case 2 the broker will redeliver all messages that were not acked,
> although it doesn't necessarily mean that the consumer didn't really
> consume them already. For that you should look at the redelivered flag.
> On Jan 21, 2012 11:20 PM, "Bell, Paul M." <pbell at syncsort.com> wrote:
>
>> I apologize. I should have stated up front that the queues and messages
>> are durable.
>>
>> What happens in case 2, where the consumer bounces?
>>
>> Thanks, Jason.
>>
>> -Paul
>>
>> ________________________________________
>> From: Jason J. W. Williams [jasonjwwilliams at gmail.com]
>> Sent: Saturday, January 21, 2012 5:05 PM
>> To: Bell, Paul M.
>> Cc: rabbitmq-discuss at lists.rabbitmq.com
>> Subject: Re: [rabbitmq-discuss] Lack of Ack, Failure and Re-delivery
>>
>> Hi Paul,
>>
>> If the messages were published with the durable flag and the queues are
>> durable, the messages will survive the broker restart and be re-presented
>> to consumers. If the messages or the queues were not durable they will
>> disappear after restart.
>>
>> -J
>>
>> Sent via iPhone
>>
>> Is your email Premiere?
>>
>> On Jan 21, 2012, at 14:57, "Bell, Paul M." <pbell at syncsort.com> wrote:
>>
>> > Hi,
>> >
>> > Suppose I have a producer on NodeP, a broker on NodeB, and a consumer
>> on NodeC. Suppose further that explicit acks are required (i.e., if I've
>> understood the docs, that "noack" is not in effect) and that after
>> consuming a message from the queue, NodeC.consumer dispatches some other
>> work in order to process that message. IOW: NodeC.consumer doesn't respond
>> immediately with an ack.
>> >
>> > So, from NodeB.broker's point of view, the message has been moved from
>> the exchange to the queue, consumed, but not yet ack-ed.
>> >
>> > What will happen under these two scenarios:
>> >
>> > 1. NodeB.broker bounces - when broker restarts what will he do with
>> un-acked messages that have been delivered to queue and haven't been
>> ack-ed; e.g., will these be again delivered to the queue?
>> >
>> >
>> > 2. NodeC.consumer bounces - when consumer restarts is there any way he
>> can again consume the un-acked message, and begin again the work that this
>> message represents? (I suppose that NodeB.broker might be implicated here
>> because it might detect the loss of connection to the NodeC.consumer....).
>> >
>> >
>> > When I say "bounces," I mean at a minimum that the application (broker,
>> consumer) crashed and restarted. But I am also interested in the case where
>> the node's OS is for whatever reason rebooted. Perhaps it looks no
>> different.
>> >
>> > Thanks for your help.
>> >
>> > -Paul
>> >
>> >
>> >
>> > 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.
>> > _______________________________________________
>> > rabbitmq-discuss mailing list
>> > rabbitmq-discuss at lists.rabbitmq.com
>> > https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120121/31fecda0/attachment.htm>