Troubleshooting JMS Connector - Mule 4

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 JMS server.

To gather detailed logs:

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.

Usually when JMS 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.

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.

The configuration of HA (High Availability) systems consists of two components:

Both nodes are identical and are ready to receive requests so the end-user is not aware of the system crash and can continue to use the system transparently.

However, when you work with durable subscriptions, only one node initializes a connection while the other node fails to do it. In these scenarios, the nodes are identical, but both of them cannot be ready at the same time. That’s because one node has a connection while the other one doesn’t. The current design of Mule running in HA clusters aims that all nodes initialize connections to ensure that they are capable of facing a failure of the primary node.

Because of these reasons, JMS Connector does not support durable ActiveMQ subscriptions in HA cluster environments.

To resolve this scenario:

Implement a fallback solution by managing the life cycle of containers to detect when the primary node fails and starts a new node.

A known issue is that a JMS driver or broker prefetch configuration combined with MANUAL ACK and concurrent consumers or consuming more than one message per flow lead to an unexpected ordering of the consumed messages.

JMS brokers implement prefetch policies for efficient usage of network resources using a push model to dispatch messages to consumers, ensuring that a consumer always has a local buffer of messages ready to process. When the JMS driver or broker has a prefetch size configuration, each consumer holds a buffer of messages ready to consume. The number of messages in the buffer depends on the broker implementation and custom parameterization.

The JMS Connector Consume operation consumes one message at a time using a per operation consumer, which means that each operation holds a buffer of messages, but the operation consumes only the first message in the buffer by design. Which results in an unexpected behavior in the order in which messages are consumed. Consider the following scenarios:

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