Custom JMS acknowledgment and client acknowledgment auto-ack messages

[Hanshiet]

When you configure a JMS listener with SessionAcknowledgeMode set to CLIENT_ACKNOWLEDGE or a custom mode like the UNORDERED_ACKNOWLEDGE mode of AWS SQS, messages are deleted from the SQS after receiving and processing them without a specific message.acknowledge() call.

After searching through debugging and the code, it seems that the problem lies in the combination of the commitIfNecessary function (located in spring-framework/spring-jms/src/main/java/org/springframework/jms/listener/AbstractMessageListenerContainer.java) and the isClientAcknowledge function (located in spring-framework/spring-jms/src/main/java/org/springframework/jms/support/JmsAccessor.java).

The isClientAcknowledge function was committed on 2023/06/12 with the following code:

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);
}

And a specific message:

"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."

However, commitIfNecessary, called always in the last line of doExecuteListener in the same class, commits the message with the condition "isClientAcknowledge(session)":

protected void commitIfNecessary(Session session, @Nullable Message message) throws JMSException {
    // Commit session or acknowledge message.
    if (session.getTransacted()) {
        // Commit necessary - but avoid commit call within a JTA transaction.
        if (isSessionLocallyTransacted(session)) {
            // Transacted session created by this container -> commit.
            JmsUtils.commitIfNecessary(session);
        }
    }
    else if (message != null && isClientAcknowledge(session)) {
        message.acknowledge();
    }
}

Is this correct? Commit should only be necessary in SESSION_TRANSACTED, AUTO_ACKNOWLEDGE, and DUPS_OK_ACKNOWLEDGE modes. Probably the correct condition is:

else if (message != null && !isClientAcknowledge(session))

[vpavic]

There's some background in the comments of the PR that introduced this change:

• Handle custom JMS acknowledgment modes as client acknowledge #30619

[jhoeller]

Note that there is no notion of actual client-side acknowledgment in a message listener container setup. It rather semantically means "let the Spring message listener do the acknowledgment" (which is client-side from the message broker perspective) rather than "let the message broker itself do an auto-acknowledge".

If a custom message listener does not want to accept a message, it needs to throw an exception and cause a rollback step which the message listener container translates into a rollback/recover step. Otherwise, the message is always going to be committed/acknowledged.