---
schema_version: "1"
id: a84852cc9bdd6fb8a10cafa190e778654de3986a0498b02b8d086d53accb4d8b
title: JMS Tuning For Performance
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/jms-connector/1.2/jms-performance.md
canonical_url: https://docs.mulesoft.com/jms-connector/1.2/jms-performance
source_site: docs.mulesoft.com
content_type: documentation
content_hash: ac199896fbb1d8771e646ec15029031c910cdc4de88415d7c3fb37f00541de89
description: MuleSoft Documentation Site
release: "1.2"
latest: false
---
---
product: JMS Connector
version: 1.2
keywords: jms, connector, consume, message, source, listener
---

# JMS Tuning For Performance

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

Performance can be a big factor when processing loads of messages, which means that you probably
want to check the following configurations to make sure you get the most out of the JMS Connector.

## Don’t Disable Connections Reuse

Connections are expensive to create, so it’s important to reuse them as much as possible.

**By default, the JMS Connector uses an aggressive** `caching-strategy` that reuses as much
Consumers and Producers as possible. It is recommended to keep this configuration untouched, since
any modification could reduce the performance of your application.

> [!WARNING] Disabling connections caching will reduce the performance of your application.

## Increasing Concurrent Messages Processing

A good way of improving the performance of your application is to increase the number of concurrent
consumers that receive messages from the same destination. This can be done easily in the JMS
Connector by configuring the `numberOfConsumers` parameter.

Out of the box, the `listener` will use **four consumers** concurrently on the same destination, but
you can increase this number to the one that fits better your needs:

```xml
<jms:listener config-ref="config" destination="#[vars.destination]" numberOfConsumers="20"/>
```

> [!TIP] Increasing the `numberOfConsumers` is the easiest way to improve the throughput of your
> listeners.

## Optimize Your Configuration For Clusters

For applications running in clusters, you have to keep in mind the concept of **primary node** and
how the connector will behave. When running in a cluster, the JMS `listener` **default behavior will
be to receive messages only in the _primary node_**, no matter what kind of destination you are
consuming from.

In case of consuming messages from a **Queue**, you’ll want to **change this configuration to
receive messages in all the nodes** of the cluster, not just the primary. This can be done with the
`primaryNodeOnly` parameter:

```xml
<jms:listener config-ref="config" destination="${inputQueue}" primaryNodeOnly="false"/>
```

Consuming messages from a **Topic** is a bit different, since the default behavior of **receiving
messages only in the primary node is the most common use case**, given that it avoids processing the
same message multiple times across the cluster.

If you are using the JMS 2.0 **shared subscriptions** mechanism, then you’ll want to **change the
cluster configuration to consume from all the nodes**, again setting `primaryNodeOnly` to `false`:

```xml
<jms:listener config-ref="JMS_20_config" destination="${inputTopic}" primaryNodeOnly="false">
     <jms:consumer-type>
         <jms:topic-consumer shared="true" subscriptionName="clusteredEventListener"/>
     </jms:consumer-type>
 </jms:listener>
```

> [!TIP] When listening from a **Queue** in a cluster, change the `primaryNodeOnly` configuration to
> `false`.

> [!WARNING] When listening from a **Topic** in a cluster, not using the `primaryNodeOnly`
> configuration will cause the cluster to process the same message more than once, unless
> shared-subscriptions is used.

## See Also

- [To Consume Messages](https://docs.mulesoft.com/jms-connector/1.2/jms-consume)

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