activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <>
Subject Re: ActiveMQ redelivering acknowledged messages
Date Tue, 25 Nov 2014 15:47:11 GMT
Gary Tully, does the first change Sergiy referenced (
really disable CLIENT_ACKNOWLEDGE from 5.10 onward, or is he
misunderstanding the change you made?  If he's got it right, can you please
explain why that option is no longer supported?

On Tue, Nov 4, 2014 at 7:37 AM, sbarlabanov <>

> I double checked everything and did a little bit debugging.
> According to the current state of ActiveMQ code (5.10) , it may indeed
> loose
> acknowledgements.
> 1. Since 5.10 CLIENT_ACKNOWLEDGE is ignored in the application server - see
> the commit adb49f56 by Gary from 15.03.2014. This was quite a strange
> commit, since this was a very important change breaking the previous
> behavior even if it had not been really spec conform - it did work since
> years and suddenly it was changed without any corresponding Jira and any
> public information.
> Now AUTO_ACKNOWLEDGE is used instead.
> 2. Despite stating that
> persistent messages are sent synchronously outside a transaction, the ACKs
> are sent ASYnchronously outside a transaction in an application server by
> default (and I did not find any property which would change this behavior).
> Since the ACKs are sent asynchronously, they may be lost obviously. And the
> corresponding messages will be redelivered. This is quite a big pain since
> everybody would expect an acknowledge of a persistent message to be
> synchronous regardless whether it is AUTO_ACK or CLIENT_ACK.
> So the workaround in our case is to use JTA transactions instead of
> CLIENT_ACKNOWLEDGE and Message#acknowledge. This would be at least more
> spec
> conform.
> But nevertheless it would be nice to see any comments from ActiveMQ
> developers about points 1 and 2 I described above.
> --
> View this message in context:
> Sent from the ActiveMQ - User mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message