activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TLFox <>
Subject Asynchronous acknowledgements - are they correct?
Date Fri, 16 May 2008 15:32:33 GMT

Looking through the ActiveMQ 5 code I noticed that all acks are sent from the
client to the server asynchronously (i.e. the client doesn't block waiting
for a response from the server to say the ack arrived and was processed).

Considering the above I am trying to understand how JMS semantics can be

Consider the case of a CLIENT_ACKNOWLEDGE jms session.

With CLIENT_ACKNOWLEDGE, when the acknowledge() method is invoked, all
messages consumed thus far in the session should be acknowledged. When the
call to acknowledge() returns the caller should be sure in the fact that the
messages have been successfully acked and the messages won't be redelivered.

If however, the acks are sent asynchronously then it is likely they will be
actually acked on the server some time after the call to acknowledge() has

This means that if the server crashes in the period between acknowledge()
being called and the acks actually being acked on the server, then, on
recovery of the server the messages will be redelivered! Even though the
client thought they were successfully acked.

A similar issue seems to exist with AUTO_ACKNOWLEDGE. With AUTO_ACKNOWLEDGE,
according to the JMS spec, "at most once delivery" is supposed to occur.
This means if the server crashes, the message might be lost, but it will
never be delivered more than once (hence "at most once").

With ActiveMQ since the acknowledgement is sent asynchronously, if the
server crashes between the ack being sent and being received on the server,
the message may get redelivered on recovery. It seems to me this breaks JMS

Perhaps I am missing something obvious here? Can someone advise?

Thanks in advance
View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message