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