6 Replies Latest reply on Jul 12, 2006 1:01 PM by Tim Fox

    Asynchronous acknowledgements

    Tim Fox Master

      I may be mistaken - but I think I remember someone once mentioning that acks can be sent asynchronously from the client to the server.

      I'm trying to understand how this can work, since it seems to me it can result in race concditions, for instance:

      Imagine the following:

      1. Client acks message A asynchronously
      2. Client calls session.recover()
      3. (asynch ack hasn't arrived at server yet) - Server resends message A since it thinks it's not acked yet
      4. Client receives message A again event thought they acked it.
      ??

      Any ideas?

        • 1. Re: Asynchronous acknowledgements
          Tim Fox Master

          Ok this is probably not a good example since session recovery can be handled on the client side, but I suspect there are others...

          • 2. Re: Asynchronous acknowledgements
            Adrian Brock Master

            It is NACKs that can be asynchronous.

            ACKs can be asynchronous if you use DUPS_OK
            (e.g. you can bundle them with the next server request)

            • 3. Re: Asynchronous acknowledgements
              Tim Fox Master

              What's the purpose of a NACK?

              afaik we don't use them in messaging, unless we're using a different terminology...

              • 4. Re: Asynchronous acknowledgements
                Adrian Brock Master

                You must have some notion of NACKs, otherwise how do you handle
                all the cases that need redeliveries?

                e.g. An error during a message listener

                e.g.2. Closing a CLIENT_ACKNOWLEDGE session without
                acknowledging the messages

                e.g.3. closing the receiver there is a race condition
                on the server delivering a message

                receiver -> I want a message
                server -> there is none, just wait
                sender -> send message
                server -> queue delivery of message
                receiver -> close()
                delivery -> Oh! The receiver has vanished -> NACK!

                etc.

                • 5. Re: Asynchronous acknowledgements
                  Adrian Brock Master

                  For some simple examples, look at
                  org.jboss.test.jbossmq.test.UnackedUnitTestCase

                  • 6. Re: Asynchronous acknowledgements
                    Tim Fox Master

                     

                    "adrian@jboss.org" wrote:
                    You must have some notion of NACKs, otherwise how do you handle
                    all the cases that need redeliveries?

                    e.g. An error during a message listener


                    The spec says that for auto ack or dups_ok then the same message must be redelivered immediately. No need to send anything to the server here since we already have the message on the client and we just retry the onMessage method up to a maximum number of times.


                    e.g.2. Closing a CLIENT_ACKNOWLEDGE session without
                    acknowledging the messages


                    In this case when the sesssion closes, the server gets the "close session" invocation and knows which messages have been sent to the session but not acked so it just nacks (cancels) them back to the queue. No need to send a nack for each message from client to server.


                    e.g.3. closing the receiver there is a race condition
                    on the server delivering a message

                    receiver -> I want a message
                    server -> there is none, just wait
                    sender -> send message
                    server -> queue delivery of message
                    receiver -> close()
                    delivery -> Oh! The receiver has vanished -> NACK!


                    Right. In this case we send a nack from client to server. In messaging terminology we call it a "cancel" :)