On 21 May 2010 17:57, Gordon Sim <[email protected]> wrote: > On 05/21/2010 02:43 PM, Martin Ritchie wrote: >> >> On 1 April 2010 01:26, Aidan Skinner<[email protected]> wrote: >>> >>> I've recently been wrestling with transaction handling in the java >>> broker in the context of 0-9-1 compliance. We're currently not >>> strictly spec compliant with 0-9-1 as we will resend messages that >>> have been rolled back. 0-9 and 0-8 are... ambiguous... on this matter, >>> and I've been trying to retain current behaviour for them. >>> >>> However, it's a) a massive PITA and b) probably Not What You Want. If >>> you're rolling back a consume it's almost certainly because you can't >>> cope with the message. >>> >>> If you think b) I'd like to float the idea of 0.8 being the "we are >>> breaking backwards compatibility" release so we can fix the conf file, >>> the command line etc. >>> >>> Thoughts? >> >> I don't read the spec in the same way. >> >> From the 0-9-1 Spec: >> 1.9.2.5. Method tx.rollback (ID 30) >> This method abandons all message publications and acknowledgments >> performed in the current >> transaction. A new transaction starts immediately after a rollback. >> Note that unacked messages will not be >> automatically redelivered by rollback; if that is required an explicit >> recover call should be issued. >> >> I read that as the unacked messages will not be automatically given >> back to the client. So we should put them back on the queue and let >> the client fight it out with other cilents to see who gets them. > > My understanding is that they would remain in the 'acquired' state, not > acked but not requeued. The client could then decide to call recover > explicitly to either requeue them or have them redelivered (or it could > simply replay them itself if held locally). > > In 0-8/0-9 it was not explicitly stated that there should be a > recover(requeue=false) implied by rollback but we assumed this as the spec > did prohibit an explicit recover call for transactional sessions. 0-9-1 > explicitly stated that the recover was not implied, but allowed the recover > to be called on a transactional session if desired.
Thanks for the clarification.. Sounds like we should be calling a recover on the 0-9-1 session then, and stop the Java broker 'auto-recovering' as it is just now. > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > -- Martin Ritchie --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
