Asynchronous acknowledgements - are they correct?

[TLFox]

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 maintained.

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 returned.

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 semantics.

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

Thanks in advance

[rajdavies]

On 16 May 2008, at 16:32, TLFox wrote:

>
> 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
> maintained.
>
> 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
> returned.
>
> 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
> semantics.
>
> Perhaps I am missing something obvious here? Can someone advise?
>
> Thanks in advance
> --
> View this message in context: http://www.nabble.com/Asynchronous-acknowledgements---are-they-correct--tp17277656s2354p17277656.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

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. Ultimately, messaging is  
asynchronous - and the JMS spec states that applications should cater  
for the case where redeliveries can occur.






cheers,

Rob

http://open.iona.com/products/enterprise-activemq
http://rajdavies.blogspot.com/

[TLFox]

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.

[rajdavies]

Well - we could always make synchronous acks optional :)

On 16 May 2008, at 19:04, TLFox wrote:

>
> 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: http://www.nabble.com/Asynchronous-acknowledgements---are-they-correct--tp17277656s2354p17280899.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

[TLFox]

rajdavies wrote:

Well - we could always make synchronous acks optional :)

That sounds like a good solution :)

I'd suggest a flag in activeMQ "strictJMSCompliance" which would cause acks to be synchronous.

Thanks again.