3 Replies Latest reply on Dec 1, 2006 9:44 AM by Tim Fox

    Can acknowledgements be asynchronous for auto_ack?

    Tim Fox Master

      It's my understanding that NACKs (cancels) can always be sent asynchronously from the client to server, since it won't affect the reliability guarantee if they are lost for some reason.

      However, with ACKs then, if the ACK fails, the client needs to know this, in the case of CLIENT_ACKNOWLEDGE, or transactional (where the commit does an implicit ack of the messages), therefore the call to acknowledge needs to be synchronous.

      However with DUPS_OK, duplicates may happen anyway, therefore we can get away with asynchronous acks, since if one is lost this may result in redelivery which we are ok with anyway.

      What about AUTO_ACK? Does the ack need to be synchronous in this case?

      With auto_ack without a message listener, the message is acked before it is processed. So messages could be lost anyway, if the client fails. So the once and only once does not apply anywhere. Since the reliability guarantee is lower is it acceptable to use asynchronous acks with AUTO_ACK as well?

        • 1. Re: Can acknowledgements be asynchronous for auto_ack?
          Adrian Brock Master

          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?
            Tim Fox Master

             

            "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?
              Tim Fox Master

              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.