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
JMS specifications has a couple of constraints/limitations:
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.
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.
The text was updated successfully, but these errors were encountered:
JMS specifications has a couple of constraints/limitations:
Jackarta group proposed to remove this constraint, but it's still there.
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.
The text was updated successfully, but these errors were encountered: