[rabbitmq-discuss] Ordering of redelivered messages?

[Marek Majkowski]

On Fri, Jan 28, 2011 at 15:16, Grzegorz Nosek <root at localdomain.pl> wrote:
>>> So "delivered" means to a queue, not to a consumer,
>>
>> Both, depending on context :)
>
> Oh. ;)
>
>> A queue is a FIFO structure.
>>
>> When you do "basic_consume" or "basic_get", from your
>> program (let's call this program a "consumer"), a message
>> gets send over the wire from the server to the consumer,
>> and it's delivered to your "consumer".
>>
>> At that point two things can happen:
>
> (...)
>
> Well, we didn't even get to that point as the only consumer disconnected a
> few seconds earlier leaving an empty, non-autodelete queue. Does the first
> consumer binding to a queue trigger:
>
> a) _delivery_ of the accumulated messages (with ordering preserved)
>
> or
>
> b) _redelivery_ (with no ordering guarantees)
>
> ?
>
> If a) is true, then I screwed up somewhere else and need to find out where
> but if b) is the case, then it explains what I have seen even if it's not
> intuitive (who was the original delivery to, if this new consumer is the
> first one these messages have ever seen?)

Rather a). I guess you forgot to call "basic_ack" after a message.
Check out the "forgotten acknowledgement" box here:
  http://www.rabbitmq.com/tutorial-two-python.html

When first consumer "subscribes" to a queue (using basic_consume),
messages will be just delivered to it. Without 'basic_qos(prefetch_count)'
*all* the messages will be immediately delivered to that consumer.
(note: that's not exactly true).

Nothing else happens on subscription.

The "redelivery of unacked messages back to the queue" happens when
consumer gets *disconnected*.