Handling Message Acknowledgement

There are different acknowledgement configurations provided by the JMS Connector.

Automatic Acknowledgement On Success

The AUTO ackMode can be used in the jms:listener component, causing the automatic ACK of the received Message if and only if the flow execution completes successfully. In case that an error occurs during the flow execution that causes it to terminate prematurely, then the Message will not be ACKed and redelivery will occur.

Another ackMode similar to AUTO is DUPS_OK. With DUPS_OK the Message is acknowledged automatically upon success of the flow execution but in a lazy fashion which may lead to duplicates since the Message may be redelivered before the ACK is performed.

Immediate Acknowledgement

Setting the ackMode to IMMEDIATE either in jms:listener or jms:consume operations will cause the Message to be automatically ACKed once it is consumed, and prior to any processing of the Message by the application. Having the Message automatically acknowledged once it is received means that the Message won`t be redelivered if any error occurs during the processing of the Message, so application logic like a dead letter queue has to be created to handle errors without losing Messages.

Manual Acknowledgement

As you may expect, the MANUAL ackMode delegates all the responsibility of performing the ACK on the Message to the application logic.

With this configuration, every Message received by either the listener or consume operations will have an ackId available in the MuleMessage attributes which identifies this Message uniquely for a given connection.

The ackId that identifies the Message will then be passed on to the jms:ack operation:

<flow name="consumerWithManualAck">
    <jms:consume config-ref="JMS_config" destination="openTickets" ackMode="MANUAL"/>

    <!--Do message processing-->
    <logger message="#[payload]">

    <jms:ack ackId="#[attributes.ackId]"/>
</flow>

Manual Session Recovery

When using the MANUAL ackMode, all Messages that are received but not acknowledged won`t be redelivered by the broker. In case of an error that occurs during the Message processing that prevents it from being ACKed, the user is responsible for manually recovering all the Messages in the Session that have to be redelivered using the recover-session operation:

<flow name="consumerWithManualAck">
    <jms:consume config-ref="JMS_config" destination="${destination}"
                 ackMode="MANUAL" target="consumedMessage" targetValue="#[message]"/>

    <!--Do message processing-->
    <logger message="#[payload]">

    <jms:ack ackId="#[vars.consumedMessage.attributes.ackId]"/>

    <error-handler>
        <on-error-propagate>
            <!--In case of error, recover the session-->
            <jms:recover-session ackId="#[vars.consumedMessage.attributes.ackId]"/>
        </on-error-continue>
    </error-handler>
</flow>

Same as before, the Connection used for recovering the session has to be the same as the one used for receiving the Message.