Re: Asynchronous acknowledgements - are they correct?

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