[rabbitmq-discuss] Consuming a Rollbacked Message

Sun Apr 26 13:30:48 BST 2009

Dear Tony,

I noticed your point. I wish this information what somewhere on site, since there is very little reflected about transactions in rabbitmq documents. 

For example I did not know before your mail that transactions are for acks and publish and not for deliver. This looks really odd for most of us whom have used to transactional consumers.

Then what is your proposed solution for this case? I don't like the reconnect model and is basic.recover the last alternative? How should I call it? periodically? I see basic.recover in docs but dono how to use it. 

Kind Regards and thanks for your help,
Amin Abbaspour

--- On Sun, 4/26/09, Tony Garnock-Jones <tonyg at lshift.net> wrote:

> From: Tony Garnock-Jones <tonyg at lshift.net>
> Subject: Re: [rabbitmq-discuss] Consuming a Rollbacked Message
> To: abbaspour_amin at yahoo.com
> Cc: rabbitmq-discuss at lists.rabbitmq.com
> Date: Sunday, April 26, 2009, 2:07 PM
> Hi Amin,
> 
> Amin Abbaspour wrote:
> > What I can? Is there something wrong with my rollback
> or ACK
> > mechanism? should I do something more than a simple
> txRollback()?
> 
> TX-class transactions introduce grouping and limited
> atomicity for *publishes* and *acknowledgements*. This means
> that the scope of a transaction is only those basic.publish
> and basic.ack operations that the client has performed
> within the transaction. In particular, basic.delivers are
> not included in a transaction -- so it would be wrong for
> the server to resend them on a rollback!
> 
> A rollback, then, does not release any messages to other
> consumers, or cause them to be redelivered to this one; it
> is assumed by the server that since the client has seen the
> messages, and has clearly not crashed (since the connection
> is still open and healthy), there is no need to resend them.
> The server can trust the client in this case to continue
> thinking about which messages to acknowledge, and will wait
> for subsequent basic.acks followed by tx.commit.
> 
> If the client has forgotten what it has seen, it can use
> the basic.recover operation to get its pending deliveries
> resent. Alternatively, it can close and reopen the channel
> (though this has other consequences).
> 
> This is a confusing area of the spec: not only did we
> initially get our implementation wrong, other
> implementations did too, and in fact the 0-8 spec does not
> fully specify the behaviour of rollbacks or basic.recover
> operations. Furthermore, there is a legitimate, if subtle,
> design question here: seen one way, the current behaviour --
> transactional acks -- is correct; seen another, the
> alternative -- transactional deliveries -- is correct. (If
> you're interested, the former seems natural in a
> hub-and-spoke design for AMQP, but the latter starts to look
> oddly sensible in a fully peer-to-peer, internet-scale
> design...)
> 
> Regards,
>   Tony