Skip to content

AbstractMessageListenerContainer#doExecuteListener can cause a dropped message if using CLIENT_ACKNOWLEDGE and the container is stopped and subsequently started again. [SPR-12015] #16631

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

Closed
spring-projects-issues opened this issue Jul 21, 2014 · 2 comments
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: backported An issue that has been backported to maintenance branches type: bug A general bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Jul 21, 2014

James Reitz opened SPR-12015 and commented

This probably affects much later versions of Spring as well, but I haven't confirmed it yet (looks that way from comparing this class with the 4.0.4 release).

  1. configure your listener container for CLIENT_ACKNOWLEDGE acknoledgement mode, and CACHE_CONSUMER level caching.
  2. use a shared JMS connection (may not be required)
  3. call stop() on the DMLC when the listener container is in a javax.jms.MessageConsumer#receive() call.
    • If the receive() call returns with a message, the AbstractMessageLIstenerContainer#doExecuteListener() method will not process the message. It will throw a MessageRejectedWhileStoppingException which is quietly ignored.
  4. Now call start() The next message from the JMS destination is received and if processed successfully, is acknowledged. This acknowledges all previously received messages...including the one that was rejected. Thus, the rejected message is never redelivered, even though it was never processed.

It seems like, when rejecting the message, recover should be called on the JMS session. This would cause the message to be redelivered.

A work-around is to call AbstractMessageListenerContainer#setAcceptMessagesWhileStopping(true); which prevents the message from being initially rejected.

This problem was seen in a production application using Tibco, but I don't believe the problem is provider specific.


Affects: 3.1.4

Issue Links:

Referenced from: commits 902303b, 7af1e00, c082220

Backported to: 3.2.11

4 votes, 3 watchers

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Good point, and fixed for 4.1 RC2 now. I'll also backport this to 4.0.7 and 3.2.11.

Juergen

@spring-projects-issues
Copy link
Collaborator Author

James Reitz commented

Great. Thanks Juergen!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: backported An issue that has been backported to maintenance branches type: bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants