---
schema_version: "1"
id: 20f2cef1bfc8157e22e5b4f45d656cd9da4d79bff89e2a42bc05f22a19dbb3fa
title: Troubleshooting IBM MQ Connector
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/ibm-mq-connector/1.7/ibm-mq-troubleshooting.md
canonical_url: https://docs.mulesoft.com/ibm-mq-connector/1.7/ibm-mq-troubleshooting
source_site: docs.mulesoft.com
content_type: documentation
content_hash: aebd80a32e731cef2c9456b18357484cc4bcbcd35dc9be74262cc617194831a7
description: MuleSoft Documentation Site
release: "1.7"
latest: false
---
---
product: IBM MQ Connector
version: 1.7
---

# Troubleshooting IBM MQ Connector

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

To troubleshoot Anypoint Connector for IBM MQ (IBM MQ Connector), become familiar with the
information about enabling verbose logging, troubleshooting acknowledgment issues, troubleshooting
MQ stopped consuming messages, troubleshooting redeployment errors when using binding mode, and
interpreting commonly thrown messages.

## Enable Verbose Logging

Sometimes you are not sure why the application is failing and you require a better understanding of
what is going on in the app’s interaction with the MQ server.

To gather detailed logs:

- Use the configuration file to increase the logging level on the server side.

- Enable verbose logging for JMS Connector and MQ packages:

  1.  Access Anypoint Studio and navigate to the **Package Explorer** view.

  2.  Open your application’s project name.

  3.  Open the `src/main/resources` path folder.

  4.  Open the `log4j2.xml` file inside the folder.

  5.  If the following line is already in the `log4j2.xml` file, uncomment it to enable it;
      otherwise, add it:

      ```xml
          <AsyncLogger name="com.mulesoft.connectors.ibmmq" level="DEBUG"/>
          <AsyncLogger name="org.mule.jms.commons" level="DEBUG"/>
      ```

## Troubleshoot Acknowledgment Issues

There are several ways an application setup can be inconsistent in terms of message acknowledgment.
You can configure the session acknowledgment for an application as:

- **IMMEDIATE**

- **AUTO**

- **MANUAL**

- **DUPS\_OK**

When you set the session acknowledgment to **IMMEDIATE**, the message gets acknowledged as soon as
it’s received. Do not mix **IMMEDIATE** acknowledgment with **Ack** or **Recovery session**
operations.

When you set the session acknowledgment to **AUTO**, the **On New Message** source takes control of
the acknowledgment when the event finishes, or the session recovers when an error is thrown while
processing the event. Adding a manual acknowledgment or session recover in an application with
**AUTO** acknowledgment leads to duplicate operations on a channel.

When you set the session acknowledgment to either **MANUAL** or **DUPS\_OK**, check that every path
of the flow execution gets a message acknowledgment or a session recover. Otherwise, a message can
leak and lead to an unresponsive consumer when the max depth of the unit of work is reached.

To resolve this issue:

Take a detailed look at the flow design and be sure that every message is acknowledged or the
session recovers.

## Troubleshoot MQ Stopped Consuming Messages

Usually when MQ stopped consuming messages is related to a large number of unacknowledged messages.
When your Mule app that has an **On New Message** source or **Consume** operation with manual
acknowledgement of messages, and not every path of the message has the proper acknowledgement or
session recovery configuration, the Mule app can lead to an unresponsive consumer.

To resolve this error:

Check the depth of unacknowledged messages on the broker side and review the application logic.

## Troubleshoot Redeployment Errors When Using Binding Mode

When using binding mode for connections, the driver loads a JNI resource. Because the JNI resource
can be loaded only once, when the application is redeployed, an error is thrown.

To resolve this error:

Add the driver dependency at the domain level, which enables application redeployment.

## Understand Common Throws

Here is a list of common throw messages and how to interpret them.

- IBM-MQ:ACK

  There was an error in the context of the acknowledgment of an inflight message.

- IBM-MQ:CONNECTIVITY

  The connection is no longer valid. It is disposed of, but you can apply a reconnection policy if
  defined in the application setup.

- IBM-MQ:CONSUMING

  An error occurred while consuming messages from WMQ. This error might relate to the absence of a
  pending message.

- IBM-MQ:DESTINATION\_NOT\_FOUND

  IBM MQ Connector is not able to find or create the destination.

- IBM-MQ:RETRY\_EXHAUSTED

  The maximum number of retries for the operation is reached.

- IBM-MQ:SECURITY

  The thrown exception in due to of security-related errors.

- IBM-MQ:TIMEOUT

  The timeout for the requested operation is exceeded.

- IBM-MQ:ILLEGAL\_BODY

  The message body is invalid or cannot be converted to a supported type.

- IBM-MQ:PUBLISHING

  There is an error while publishing to the target queue or topic.

## See Also

- [IBM MQ Connector Reference](https://docs.mulesoft.com/ibm-mq-connector/1.7/ibm-mq-xml-ref)

- [Salesforce Help](https://help.salesforce.com)

- [Known Issues](https://help.salesforce.com/s/issues)