JMS message always acknowledged even with CLIENT_ACKNOWLEDGE [SPR-12995]

[spring-projects-issues]

Thomas Diesler opened SPR-12995 and commented

On a JMS message consumer route, we support

jms:...&acknowledgementModeName=CLIENT_ACKNOWLEDGE

The pattern is that a client may chose to process a batch of msgs before it acks. If batch processing succeeds the client calls Message.acknowledge(). If it fails, the client may choose to recover the msgs in the batch with Session.recover()

In a Processor we can now call Message.acknowledge() or Session.recover(). However, even if the route (i.e. the client) does not call Message.acknowledge() it is called automatically in org.springframework.jms.listener.AbstractMessageListenerContainer

protected void commitIfNecessary(Session session, 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();
     }
}

This would not be correct if the route is the JMS client. Redelivery can only be achieved in the context of one message invocation

CrossRef: https://issues.apache.org/jira/browse/CAMEL-8711

---

Affects: 4.1.6

Issue Links:

• CLIENT_ACKNOWLEDGE with JmsTemplate - implicit message acknowledge each read [SPR-13255] #17846 CLIENT_ACKNOWLEDGE with JmsTemplate - implicit message acknowledge each read

[spring-projects-issues]

Thomas Diesler commented

Would this not need to be

else if (message != null && isAutoAcknowledge(session)) {
     message.acknowledge();
}

[spring-projects-issues]

Juergen Hoeller commented

I'm afraid this is by design... Spring's message listener containers are meant to provide a complete interaction step for every single message listener invocation, which is why they make sure to acknowledge a message in any case. Client acknowledge is simply a mode that the JMS Session may be in here, and we react to it through an explicit acknowledge call.

The underlying conceptual issue is that the listener code doesn't own the JMS Session: It rather just receives a callback for a message within a given current Session; the next callback may come from a different Session, and the original Session from the first invocation may be used for a callback to a different listener at the same time. As a consequence, there is no controlled sequence of messages that such a listener could recover; there is rather just a bunch of messages that the listener may possibly individually reject.

For a recoverable sequence of messages, direct receive calls on a locally owned JMS Session are the only way to go. Unfortunately, this is not what Spring's concurrent message listener containers are designed for. Instead, we'd recommend the use of JmsTemplate in such scenarios.

Juergen