[rabbitmq-discuss] Ordering of messages after txRollback()

Sun Jun 6 19:28:56 BST 2010

Right and that is what I am essentially asking. If txRollback on the consumer side is un-doing the ack (at least I can observe this behavior), I thought that there is a difference between how re-queue is done when simply not acking the message (to the back of the queue) vs acked message but rolled back (to the front of the queue). But i guess its already been answered in a way  that the spec is silent about ordering.

Oleg

On Jun 6, 2010, at 2:13 PM, Mark Fisher wrote:

> The only thing a rollback on the consuming side can do is *undo acks*,  
> and there's no difference between never acking and rolling back acks  
> as far as the broker is concerned. I'm just mentioning that since - if  
> I'm understanding correctly - it is a valid if limited use for TXs on  
> the consumer side.
> 
> Sent from my iPhone
> 
> On Jun 6, 2010, at 2:05 PM, "Oleg Zhurakousky"  
> <ozhurakousky at vmware.com> wrote:
> 
>> Thanks Matthew
>> 
>> Let me get this straight. TX are only for publishers, not consumers,  
>> thus the only way to implement TX behavior on the consumer side is  
>> by not sending ACK. Is that correct?
>> 
>> Since the spec is "completely silent" on the 'ordering', does that  
>> mean that when I retrieve messages initially and they come in order  
>> it is just a coincidence?
>> I was under the impression that Queue semantics imply FIFO ordering,  
>> regardless of which spec implements such Queue. Am I missing  
>> something?
>> 
>> Cheers
>> Oleg
>> 
>> 
>> On Jun 6, 2010, at 1:32 PM, Matthew Sackman wrote:
>> 
>>> On Sun, Jun 06, 2010 at 09:58:20AM -0700, Oleg Zhurakousky wrote:
>>>> I have a simple test where I receive 20 messages in the order in  
>>>> which they came in, then rollback each and every one of them.
>>>> 
>>>> Upon the next attempt to receive messages the order is completely  
>>>> arbitrary. Is this by design?
>>> 
>>> Yes, pretty much. Not quite sure what you mean by rollback though:
>>> Transactions are only on what you send to the server, not what it  
>>> sends
>>> to you. I suspect you're not meaning to use transactions and are
>>> actually just closing the connection or channel on which you've  
>>> done the
>>> consume, which will cause all unacked messages to be requeued. If you
>>> use basic.recover{requeue=true} then the order will be more  
>>> predictable,
>>> however, that's a facet of the design: the spec is completely  
>>> silent on
>>> the order, and you should not rely on RabbitMQ doing any particular
>>> ordering.
>>> 
>>> Matthew
>>> _______________________________________________
>>> rabbitmq-discuss mailing list
>>> rabbitmq-discuss at lists.rabbitmq.com
>>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>> 
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss