-
1. Re: Can acknowledgements be asynchronous for auto_ack?
adrian.brock Dec 1, 2006 9:26 AM (in response to timfox)No. Consider the following:
Synchronous:
Client: receive(); -> server
Client: AUTO_ACK -> synch
Client: process message (only once)
Client: Crash
Client: Reboot
Client: Cannot re-receive the message
Asynchronous:
Client: receive(); -> server
Client: AUTO_ACK -> asynch
Client: process message
Client: Crash (the asynch ACK never made it to the server)
Client: Reboot
Client: Can re-receive (and reprocess!) the unacked message
In fact, part of the contract of receive() for AUTO_ACK is that
the ACK has been successfully done such that when the client
does processing on the message, it knows that it won't get the message again. -
2. Re: Can acknowledgements be asynchronous for auto_ack?
timfox Dec 1, 2006 9:33 AM (in response to timfox)"adrian@jboss.org" wrote:
In fact, part of the contract of receive() for AUTO_ACK is that
the ACK has been successfully done such that when the client
does processing on the message, it knows that it won't get the message again.
Thanks for the clarification.
Right, this is a "at most once" guarantee I guess, since the message might be lost if failure happened between acking and the client actually getting the message. -
3. Re: Can acknowledgements be asynchronous for auto_ack?
timfox Dec 1, 2006 9:44 AM (in response to timfox)BTW, the reason I wanted to check this, is that a certain very popular open source messaging system (you know the one I mean ;) ), in it's out of the box configuration, batches up acks in AUTO_ACK_MODE - so basically AUTO_ACK has the same delivery guarantee as DUPS_OK, which seems somewhat disingenuous, but probably helps them on benchmarks.
Which leads to the question of whether our out of the box configuration should be JMS spec compliant, or optimised for performance and the user has to actively set a flag --JMScompliant. Currently we are out of the box JMS spec compliant.