---
schema_version: "1"
id: 116cf094ae7bdb9e6372eb7dd5981748805827c2cecd36014cdcc1651faf2363
title: Handling Message Acknowledgement
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/ibm-mq-connector/1.7/ibm-mq-ack.md
canonical_url: https://docs.mulesoft.com/ibm-mq-connector/1.7/ibm-mq-ack
source_site: docs.mulesoft.com
content_type: documentation
content_hash: edf129035926de10520a82936aea7a186b05e8c7493dae8038f6bb0477fb80c0
description: MuleSoft Documentation Site
release: "1.7"
latest: false
---
---
product: IBM MQ Connector
version: 1.7
keywords: jms, connector, consume, message, ack
---

# Handling Message Acknowledgement

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

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:

```xml
<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]"/>
</flow>
```

### 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:

```xml
<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]"/>

    <error-handler>
        <on-error-propagate>
            <!--In case of error, recover the session-->
            <ibm-mq: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.

## See Also

- [Using Topic Subscriptions](https://docs.mulesoft.com/ibm-mq-connector/1.7/ibm-mq-topic-subscription)

- [How To Listen For New Messages](https://docs.mulesoft.com/ibm-mq-connector/1.7/ibm-mq-listener)