[rabbitmq-discuss] Ordering of redelivered messages?

[Marek Majkowski]

On Thu, Jan 27, 2011 at 23:06, Grzegorz Nosek <root at localdomain.pl> wrote:
> While googling for "rabbitmq redelivery order" I found this gem:
>
> http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2009-October/005078.html
>
>> Those who rely on the broker preserving perfect [...] ordering are kind of
>> doomed.
>
> so I'm not keeping my hopes too high, but still, it shouldn't hurt too much
> to ask ;)
>
> Is there a setup (of exchanges, queues etc.) that tries to preserve ordering
> of messages when faced with consumer failure? I have a very simple setup
> consisting of a bunch of producers feeding data via a single queue to a
> consumer that stuffs it into RRD files (which must be updated in order or
> require deeper surgery involving dump/restore). At one time the consumer
> happened to fail and RabbitMQ started to buffer the messages, which then got
> redelivered in (apparently) totally random order, so RRD dropped most of
> them anyway.
>
> So, is there anything I can do to at least increase the chance of messages
> being delivered in order? I don't need a 100% guarantee and the data isn't
> mission-critical so the solution need not be absolutely bulletproof (nor
> extremely scalable as the load is basically nil).

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.

But you pay the latency costs - a new message
will be send only after the ack will be delivered to server.

Cheers,
  Marek