Asynchronous acknowledgements

[timfox]

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?

[timfox]

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

[adrian.brock]

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)

[timfox]

What's the purpose of a NACK?

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

[adrian.brock]

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.

[adrian.brock]

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

[timfox]

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" :)