activemq-users mailing list archives

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

Hello Rob - thanks for your quick reply.

rajdavies wrote:
> Your summary is correct. You can always use transactions - but even  
> then there is a window when the server could crash whilst the client  
> is waiting for a response from the commit. 

Yes that is true, but there is an important difference. If a commit returns
successfully then you know for sure that the transaction has been committed
and any acks in that transaction have been processed.

However if a call to acknowledge() returns successfully with activemq you
*do not know* that the acks have been processed.

Admittedly a call to commit() might not return successfully and the
transaction still might have been committed but that is a different story.

rajdavies wrote:
> Ultimately, messaging is  
> asynchronous - and the JMS spec states that applications should cater  
> for the case where redeliveries can occur.

The JMS spec also states that AUTO_ACKNOWLEDGE should give "at most once"
delivery semantics but with active mq it is actually giving "dups_ok"
delivery semantics (since you can get duplicates). Which I would read to be
in contravention to the spec.

You'll find that other messaging systems send acnowledgements sychronously
in order to be JMS spec compliant. (They have to). Of course this gives a
performance penalty since sending async is always going to be quicker.

I guess it's a tradeoff between reliability and correctness versus
performance, and ActivemQ has chosen the performance route.

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

View raw message