-
Notifications
You must be signed in to change notification settings - Fork 38.2k
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
Handle custom JMS acknowledgment modes as client acknowledge #30619
Handle custom JMS acknowledgment modes as client acknowledge #30619
Conversation
We could turn this around and implement protected boolean isClientAcknowledge(Session session) throws JMSException {
int mode = session.getAcknowledgeMode();
return (mode != Session.SESSION_TRANSACTED &&
mode != Session.AUTO_ACKNOWLEDGE &&
mode != Session.DUPS_OK_ACKNOWLEDGE);
} No specific configuration necessary then, so it would work out of the box for your scenario, I suppose? If that sounds feasible and you got some cycles left, feel free to update the PR accordingly and rebase it onto the 6.0.x branch for inclusion in 6.0.10. Otherwise we can try to implement that out-of-the-box approach ourselves next week. |
Thanks for the quick feedback Juergen.
Yes indeed, that would be perfect.
I missed this, and was wary about changing the default behavior in any way, but if there's no risk in doing explicit acknowledge for vendor specific acknowledge modes that not variants of client acknowledge then I'm all for it. I can update the PR according to your guidance tomorrow morning. |
This commit updates JmsAccessor to handle custom JMS acknowledgment modes as client acknowledge, which is useful when working with JMS providers that provide non-standard variations of CLIENT_ACKNOWLEDGE, such as AWS SQS and its UNORDERED_ACKNOWLEDGE mode.
This commit reduces the visibility of JmsAccessorTests and its test methods to package-private and removes unnecessary throws declarations.
7fb27d6
to
db2f1d6
Compare
PR updated according to feedback and rebased on |
This commit updates
JmsAccessor
to handle custom JMS acknowledgmentmodes as client acknowledge, which is useful when working with JMS
providers that provide non-standard variations of
CLIENT_ACKNOWLEDGE
,such as AWS SQS and its
UNORDERED_ACKNOWLEDGE
mode.The workaround (a quite tedious one) that I'm using at the moment is to subclass
DefaultJmsListenerContainerFactory
andDefaultMessageListenerContainer
and override#isClientAcknowledge
using something like this:For reference, SQS
UNORDERED_ACKNOWLEDGE
is described as: