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 ibm-mq:listener component, causing the automatic ACK of the received message if and only if the flow execution completes successfully. If an error occurs during the flow execution that causes it to terminate prematurely, then the message is not acknowledged and redelivery occurs.

Another ackMode similar to AUTO is DUPS_OK. With DUPS_OK the message is acknowledged automatically upon the 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 ibm-mq:listener or ibm-mq:consume operations causes the message to be automatically acknowledged once it is consumed, and prior to any processing of the message by the application. Having the message automatically acknowledged after 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 has an ackId available in the Mule Message attributes which identifies this message uniquely for a given connection.

The ackId that identifies the message passes to the ibm-mq:ack operation:

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

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

    <ibm-mq:ack ackId="#[attributes.ackId]"/>

Manual Session Recovery

When using the MANUAL ackMode, all messages that are received but not acknowledged won’t be redelivered by the broker. If an error occurs during the message processing that prevents it from being acknowledged, 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">
    <ibm-mq:consume config-ref="JMS_config" destination="${destination}"
                 ackMode="MANUAL" target="consumedMessage" targetValue="#[message]"/>

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

    <ibm-mq:ack ackId="#[vars.consumedMessage.attributes.ackId]"/>

            <!--In case of error, recover the session-->
            <ibm-mq:recover-session ackId="#[vars.consumedMessage.attributes.ackId]"/>

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

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub
Submit your feedback!
Share your thoughts to help us build the best documentation experience for you!
Take our latest survey!