---
schema_version: "1"
id: 30a557f247a2b73d9766f4a66c25a393d4a78318b619f0bb30fbeed1af755303
title: Handling Message Acknowledgement
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/jms-connector/1.2/jms-ack.md
canonical_url: https://docs.mulesoft.com/jms-connector/1.2/jms-ack
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 6fa3655d7cba490c26fd85cf6de07758aaf5784896246eab2f422aefb31169ac
description: MuleSoft Documentation Site
release: "1.2"
latest: false
---
---
product: JMS Connector
version: 1.2
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 `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:

```xml
<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:

```xml
<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.

## See Also

- [Using Topic Subscriptions](https://docs.mulesoft.com/jms-connector/1.2/jms-topic-subscription)

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