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

JmsSink breaks JMS specs when acknowledging messages received with session-mode=CLIENT_ACKNOWLEDGE #2403

Open
fsantagostinobietti opened this issue Dec 7, 2023 · 0 comments
Labels

Comments

@fsantagostinobietti
Copy link

JMS specifications has a couple of constraints/limitations:

  1. message acknowledgment is disallowed from a thread other than the message delivery thread of the Session that runs the MessageListeners.
    Jackarta group proposed to remove this constraint, but it's still there.
  2. JMS sessions are not thread-safe and they are only designed for serial use by one thread at a time.

JmsSink component acknowledges messages, after having sent to destination, using a different thread (see dispatch() method).
This apparently breaks constraint (1) and probably (2) also.

Of course, client behaviour depends on the actual JMS implementation.
For example IBM MQ client enforces constraint (1) and in some of my examples acknowledgments are lost or block when message is sent.
Artemis implementation looks like to have removed (1). This is probably the reason why I din't experience same issues so far.

The easiest workaround is to set session-mode=AUTO_ACKNOWLEDGE for incoming channels. This way
acknowledgment is executed immediately by the same thread that receives message and (1) holds.
It works. But in case of application crash during processing message is lost forever and no redelivery is possible.

@cescoffier cescoffier added the jms label Jan 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants