You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I looked into this I found 2 problems. One was the original problem of the acks and commits being inside the txSize loop instead of outside it. When that was fixed it meant that retry tests were failing because recovered messages were being rolled back in race conditions where they ended up not being last in a transaction that had another failure yet to come. The best way to fix that is to aggressively ack and commit as soon as a recovery is handled (this is a recognised bad message, let's get it out of the way in case we hit any more problems). We do that in Spring Batch by setting a ThreadLocal in RepeatSynchronizationManager, but I didn't want to introduce either a ThreadLocal or a repeat abstraction for the tx loop in Spring AMQP unless there was a pressing need. The compromise solution is a special exception, ImmediateAcknowledgeAmqpException, which the listener (recoverer in this use case) can use to signal to the container that it wants the acks and commits to be sent immediately.
Resolvesspring-projects#1279
Regression: spring-projects#1215
Test for abstract class should not be applied to container types, which can
be abstract.
**cherry-pick to 2.2.x**
Dave Syer opened AMQP-168 and commented
SimpleMessageListenerContainer should only commit every txSize messages (it looks like it does it for every message right now).
Affects: 1.0.0.RC1
The text was updated successfully, but these errors were encountered: