Spring Handle custom JMS acknowledgment modes as client acknowledge

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.

---

The workaround (a quite tedious one) that I'm using at the moment is to subclass DefaultJmsListenerContainerFactory and DefaultMessageListenerContainer and override #isClientAcknowledge using something like this:

class SqsJmsListenerContainerFactory extends DefaultJmsListenerContainerFactory {

    @Override
    protected DefaultMessageListenerContainer createContainerInstance() {
        return new DefaultMessageListenerContainer() {

            @Override
            protected boolean isClientAcknowledge(Session session) throws JMSException {
                return (session.getAcknowledgeMode() == SQSSession.UNORDERED_ACKNOWLEDGE);
            }

        };
    }

}

For reference, SQS UNORDERED_ACKNOWLEDGE is described as:

Non standard acknowledge mode. This is a variation of CLIENT_ACKNOWLEDGE where Clients need to remember to call acknowledge on message. Difference is that calling acknowledge on a message only acknowledge the message being called.

Comment From: jhoeller

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.

Comment From: vpavic

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.

Comment From: vpavic

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