[rabbitmq-discuss] RabbitMQ as a reliable message queue

[T-zex]

Unexpected shut down of a process (power failure) will result in
"good" message being put to the end of the queue - a very unexpected
behaviour. In case of a "bad" message application should decide that
it is bad and what should be done with it - requeue (unlikely) or get
rid of it.

On Thu, Jun 16, 2011 at 2:14 AM, Toby Corkindale
<toby.corkindale at strategicdata.com.au> wrote:
> On 15/06/11 19:54, Emile Joubert wrote:
>>
>> On 14/06/11 17:08, Jason J. W. Williams wrote:
>>>>
>>>> Is it possible to use RabbitMQ as a reliable message queue? What I
>>>> mean is to make it preserve the order of messages in queues even for
>>>> non ack'ed durable messages.
>>>> Putting non acked messages into the end of the queue just doesn't make
>>>> sence.
>>>
>>> Actually, it would be difficult to preserve the order in the case of
>>> non-ack. Let's say you've got M1, M2, M3, M4 in the queue (like the
>>> FAQ describes). If you have two consumers, and C1 is consuming M1 and
>>> C2 is consuming M2. C1 finishes, acks M1 and starts consuming M3.
>>> However, C2 fails and disconnects without acking M2, where should M2
>>> go in the order? M3 is already being consumed. The only sane approach
>>> is to treat M2 as a new submission and append it to the end of the
>>> queue.
>>
>> Yes, it is not obvious how to requeue in the presence of multiple
>> consumers. But it is possible to do better in the case of a single
>> consumer where the inconsistency can't arise. At present rabbit always
>> requeues at the back of the queue, i.e. treat it as a new message. This
>> is consistent with the spec which only guarantees ordering along the
>> same path from a single producer to a single consumer.
>
> I quite like the "send to the back of the queue" behaviour.
> In the event of a bad message that is always failing/crashing on the
> consumer, it'll get pushed to the back of the queue to allow other good
> messages to be processed.
>
> In a system where the messages are always delivered in-order, that bad
> message would effectively lock the system up.
>
> Toby
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>