We could turn this around and implement JmsAccessor.isClientAcknowledge() through exclusion of all other common JMS modes (TRANSACTED, AUTO, DUPS_OK): treating everything else as client acknowledge, leading to an explicit Message.acknowledge() call in JmsTemplate and AbstractMessageListenerContainer. Since that explicit acknowledge method is defined to be ignored on implicit acknowledge setups, it won't ever hurt to call it.

	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.

No specific configuration necessary then, so it would work out of the box for your scenario, I suppose?

Yes indeed, that would be perfect.

Since that explicit acknowledge method is defined to be ignored on implicit acknowledge setups, it won't ever hurt to call it.

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.

PR updated according to feedback and rebased on 6.0.x.