-
1. Re: Asynchronous acknowledgements
timfox Jul 11, 2006 9:30 AM (in response to 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...
-
2. Re: Asynchronous acknowledgements
adrian.brock Jul 12, 2006 5:43 AM (in response to timfox)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
timfox Jul 12, 2006 11:49 AM (in response to timfox)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 Jul 12, 2006 12:03 PM (in response to 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
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 Jul 12, 2006 12:04 PM (in response to timfox)For some simple examples, look at
org.jboss.test.jbossmq.test.UnackedUnitTestCase -
6. Re: Asynchronous acknowledgements
timfox Jul 12, 2006 1:01 PM (in response to timfox)"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" :)