[rabbitmq-discuss] Ordering of redelivered messages?

[Marek Majkowski]

On Fri, Jan 28, 2011 at 13:41, Grzegorz Nosek <root at localdomain.pl> wrote:
> W dniu 28.01.2011 14:26, Marek Majkowski pisze:
>> When a message is delivered to the consumer, with acks (no_ack=False),
>> and the consumer goes away, the message will be redelivered as
>> to the queue. It will appear as "last" element.
>>
>> So yes, in the event of a failure the ordering gets broken.
>>
>> You can reduce number of messages that will be delivered
>> to the consumer by setting basic.qos(prefetch_count=1).
>>
>> That way the consumer will at any given moment have
>> at most 1 unacknowledged message.
>
> The messages were all considered delivered_but_not_yet_acked, even though
> the consumer wasn't even connected, so after the consumer returned, all the
> messages were REdelivered from RabbitMQ's perspective, which broke the
> ordering.

Yes. The messages which are delivered-but-not-yet-acked will be redelivered
when the consumer disconnects. That breaks the ordering.

> If prefetch_count=1 had been set, there would be at most one message in this
> state, so the reordering would happen only to it (so, no effect).

Correct.

>> But you pay the latency costs - a new message
>> will be send only after the ack will be delivered to server.
>
> Not a problem for me. In any case, I suppose I could set the prefetch_count
> to something comparable to the number of independent RRD archives as they're
> updated at roughly the same intervals so I'd get low latency and minimal
> risk of data loss.

Sounds reasonable.

Cheers,
  Marek