Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SimpleMessageListenerContainer should only commit every txSize messages [AMQP-168] #1729

Closed
spring-operator opened this issue May 10, 2011 · 1 comment

Comments

@spring-operator
Copy link
Contributor

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

@spring-operator
Copy link
Contributor Author

Dave Syer commented

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.

kurenchuksergey pushed a commit to kurenchuksergey/spring-amqp that referenced this issue Oct 5, 2023
Resolves spring-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**
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants