Robert Greig wrote:
>
> In a similar vein, it's asynchronous.
>
>
Ok sorry to be a pain. But there's also an issue with doing acknowledgements
asynchronously and JMS compliance.
I raised the same issue recently with ActiveMQ which suffers from the same
problem:
http://www.nabble.com/Asynchronous-acknowledgements---are-they-correct--to17277656s2354.html
To summarise, if you send acks async it's not possible to support JMS
AUTO_ACKNOWLEDGE semantics properly. AUTO_ACKNOWLEDGE requires "at most
once" delivery guarantee. This means its ok to lose a message on failure but
you'll never get duplicates.
In order to guarantee "at most once", basically you need to ack the message
synchronously to the server before you give the message to the client via a
receive() call.
If you do that, there's a possibility of lost message if the client fails
after the ack is processed but before the receive() call returns, but
there's no possibility of the message getting delivered more than once after
falure (since it's always acked before receipt).
However if you send the ack async, then the message can actually get acked
*after* it's been giving to the user. Thus introducing a window during which
if failure occurs the message can get redelivered in contravention of JMS
spec.
--
View this message in context:
http://www.nabble.com/JMS-Acknowledgements-sent-asynchronously--tp17519565p17520108.html
Sent from the Qpid Developers mailing list archive at Nabble.com.
