Troubleshooting IBM MQ Connector - Mule 4
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:
Access Anypoint Studio and navigate to the Package Explorer view.
Open your application’s project name.
log4j2.xmlfile inside the folder.
If the following line is already in the
log4j2.xmlfile, uncomment it to enable it; otherwise, add it:
<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:
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.
There was an error in the context of the acknowledgment of an inflight message.
The connection is no longer valid. It is disposed of, but you can apply a reconnection policy if defined in the application setup.
An error occurred while consuming messages from WMQ. This error might relate to the absence of a pending message.
IBM MQ Connector is not able to find or create the destination.
The maximum number of retries for the operation is reached.
The thrown exception in due to of security-related errors.
The timeout for the requested operation is exceeded.
The message body is invalid or cannot be converted to a supported type.
There is an error while publishing to the target queue or topic.