# mulesoft JMS Connector - Full Documentation --- product: JMS Connector version: 1.2 --- # About the JMS Connector > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Connector for JMS (Java Message Service) (JMS Connector) is a widely-used API for message oriented middleware. It allows communication between different components of a distributed application to be loosely coupled, reliable, and asynchronous. JMS supports two models for messaging: - Point-to-point queues - Publish and subscribe topics JMS Connector enables sending and receiving messages to queues and topics for any message service that implements the JMS specification. ## Point-to-Point Queues In the point-to-point or queuing model, a sender posts messages to a particular queue and a receiver reads messages from the queue. Here, the sender knows the destination of the message and posts the message directly to the receiver’s queue. The point-to-point queuing model is characterized by the following: - Only one consumer receives the message. - The sender does not need to be running at the time the consumer consumes the message, nor does the consumer need to be running at the time the message is sent. - Every message that is successfully processed is acknowledged by the consumer. ## Publish and Subscribe Topics The publish-subscribe model supports publishing messages to a particular message topic. Subscribers can register to receive messages on a particular message topic. In this model, neither the publisher nor the subscriber are aware of each other. An anonymous bulletin board is a good analogy for this concept. The publish-subscribe model is characterized by the following: - Multiple consumers (or none) receive the message. - The publisher must create a message topic to which clients can subscribe. - The subscriber must remain continuously active to receive messages, unless it has established a durable subscription, in which case, messages published while the subscriber is not connected are redistributed when the subscriber reconnects. ## See Also - [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors) - [Salesforce Help](https://help.salesforce.com) --- product: JMS Connector version: 1.10 keywords: jms, connector, jms_1.0.2b, jms_1.1, jms_2.0, activemq --- # Configure an ActiveMQ Connection for JMS Connector > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Connector for JMS (JMS Connector) includes an ActiveMQ connection configuration, which provides support for ActiveMQ 5. Using this connection, you can set JMS 1.1 (default), JMS 1.0.2b, or JMS 2.0 specifications, and you can configure not only all of the general connection parameters for JMS but also the custom parameters that are present only in ActiveMQ. ## Configure an ActiveMQ Connection After you declare the ActiveMQ connection, customize **Connection Factory** to your desired configuration. Every parameter in the connection comes with a default value, meaning that you are required to configure only the parameters relevant for your use case. Also, the ActiveMQ connection exposes parameters that are exclusive to the ActiveMQ implementation, like **Initial redelivery delay**. In the following example, you configure an **ActiveMQ Connection**: 1. In Studio, navigate to the **Global Elements** tab. 2. Click **Create**. 3. In the filter box type `jms` and select **JMS Config**. 4. Click **OK**. 5. In the **Connection** field select **ActiveMQ Connection**. 6. In the **Factory configuration** field, select **Edit Inline**. 7. Set the **Broker url** field value to the address of the broker to connect to, for example, `tcp://localhost:61616`. 8. Click **OK**. ![ActiveMQ Connection Configuration window in Studio with Broker URL field set to tcp://localhost:61616](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-activemq-configuration.png) In the XML editor, the `` and `` configuration looks like this: ```xml ``` ## Configure an ActiveMQ - No Connectivity Test Connection (DEPRECATED) There may be certain scenarios in which more than one node cannot use the credentials of a broker connection simultaneously. In these cases, Mule applications use the **Primary node only** field set to `true` to ensure listener execution on only one of the nodes. However, the connection test that is performed prior to deployment can result in a deployment error on the primary node if another node already used the credentials. For this particular case, use **ActiveMQ Connection - No Connectivity Test**, which is identical to the **ActiveMQ Connection**, except that it does not perform a connectivity test prior to deployment. In the following example, you configure an **ActiveMQ Connection - No Connectivity Test**: 1. In Studio, navigate to the **Global Elements** tab. 2. Click **Create**. 3. In the filter box, type `jms` and select **JMS Config**. 4. Click **OK**. 5. In the **Connection** field, select **ActiveMQ Connection - No Connectivity Test**. 6. Set the optional **Client id** field. 7. In the **Factory configuration** field, select **Edit Inline**. 8. Set the **Broker url** field value to the address of the broker to connect to, for example, `tcp://localhost:61616`. 9. Click **OK**. ![ActiveMQ Connection - No Connectivity Test Configuration window in Studio with Broker URL field set to tcp://localhost:61616](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-activemq-nct-configuration.png) In the XML editor, the `` and `` configuration looks like this: ```xml ``` ## Configure the Required Libraries When you configure any connection type, you must always configure a library containing the JMS client implementation, because JMS Connector is not bound to any particular implementation. Configure ActiveMQ external libraries in the global elements view of Studio or manually add the library dependency in your `pom.xml` file. - **ActiveMQ KahaDB** The `activemq-kahadb-store` dependency is required only when using an persistent in-memory broker based on the VM transport (such as `vm://localhost?broker.persistent=true`). This dependency provides a valid `org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter` implementation. This dependency is also required for persistent message delivery. In your `pom.xml` file in Studio, adding the dependency looks like this: ```xml org.apache.activemq activemq-kahadb-store 5.14.4 ``` - **ActiveMQ Broker** The `activemq-broker` dependency is required only when using an in-memory broker based on the VM transport (which is the one configured by default). This dependency provides a valid `org.apache.activemq.broker.Broker` implementation. In your `pom.xml` file in Studio, adding the dependency looks like this: ```xml org.apache.activemq activemq-broker 5.14.4 ``` - **ActiveMQ Client** The `activemq-client` dependency is always required to use ActiveMQ connections. Choose one that provides a valid `org.apache.activemq.ActiveMQConnectionFactory` implementation. In your `pom.xml` file in Studio, adding the dependency looks like this: - ```xml org.apache.activemq activemq-client 5.14.4 ``` To configure these libraries in the Global Element view, follow these steps: 1. In Studio, navigate to the **Global Elements** tab. 2. Click **Create**. 3. In the filter box, type `jms` and select **JMS Config**. 4. Click **OK**. 5. In the **Connection** field, select **ActiveMQ Connection**. 6. In the **Required Libraries** section that shows the **ActiveMQ KahaDB**, **ActiveMQ Broker** and **ActiveMQ Client** libraries, click the **Configure…​** button to install the dependency. 7. Select any of the following install options: - **Add recommended library** Installs the recommended library. - **Use local file** Browse to a local file for the required engine library and install it. - **Add Maven dependency** Browse to the dependency and install it. ![Click the Configure button to install the dependencies](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-activemq-libaries.png) Figure 1. JMS Connector Libraries configuration ## Configure the In-Memory Broker By default, Anypoint Connector for ActiveMQ (ActiveMQ Connector) uses an in-memory broker, which makes it easy to start building an application without configuring a connection against an external broker. The in-memory broker is required to configure both the **ActiveMQ KahaDB** and **ActiveMQ Broker** libraries. The default URL is: `vm://localhost?broker.persistent=false&broker.useJmx=false` To configure the in-memory broker in Studio, follow these steps: 1. In Studio, open the **JMS Config** global element window. 2. In the **Connection Factory** section, set the **Factory configuration** field to **Edit inline**. 3. Set the **Broker url** field to the address of the broker to connect, for example, `vm://localhost?broker.persistent=false&broker.useJmx=false` . 4. Click **OK**. ![Set the Broker url field to the address of the broker to connect](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-activemq-broker.png) Figure 2. JMS Connector In-Memory Broker Configuration In the XML editor, the `brokerUrl` configuration looks like this: ```xml ``` ## Configure Message Redelivery When a message cannot be processed correctly, it’s not acknowledged. The message is then redelivered and probably again not processed correctly, which causes the cycle to execute indefinitely. To prevent a message from endless redelivery, configure the **Max redelivery** field. By default, JMS Connector uses a maximum redelivery value of `0`, which means that messages won’t be redelivered, regardless of whether the message is recovered or rolled back from a transaction. If the message has persistent delivery set, ActiveMQ sends the message to a `DLQ.QUEUE` (a dead letter queue). ActiveMQ also enables you to configure a client-side redelivery. - The **Initial redelivery delay** field enables you to configure, in milliseconds, how much time to wait before the first message redelivers. - The **Redelivery delay** field enables you to configure, in milliseconds, how much time to wait until the message is subsequently redelivered after the first redelivery. To configure these fields in Studio, follow these steps: 1. In Studio, open the **JMS Config** global element window. 2. In the **Connection Factory** section, set the **Factory configuration** field to **Edit inline**. 3. Set the **Initial redelivery delay** field to `1000`. 4. Set the **Redelivery delay** field to `100`. 5. Set the **Max redelivery** field to `10`. 6. Click **OK**. ![Set the Max redelivery field to 10](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-activemq-redelivery.png) Figure 3. JMS Connector Redelivery configuration In the XML editor, the `maxRedelivery`,`redeliveryDelay`, and `initialRedeliveryDelay` configurations look like this: ```xml ``` ## Configure Trusted Packages ActiveMQ versions 5.12.2, 5.13.0, and later restrict the classes that can be serialized and deserialized, helping to prevent the execution of a malicious payload on the host system. For ActiveMQ, JMS Connector enables by default only the JDK and JRE provided classes, so if you need to exchange object messages, you must add the packages your applications use by activating the **Trusted packages** field. Even though you can also enable the **Trust all packages** field to allow the serialization of more classes by allowing any object to be serialized and deserialized, this is not as secure as leaving it disabled in most cases. Keep this parameter disabled to improve the security and help prevent malicious attacks. In the following example, you configure the connection to enable only users who are compliant with the `com.mulesoft.someapp` and `com.mulesoft.someapp.model` packages to consume and produce ObjectMessages: 1. In Studio, open the **JMS Config** global element window. 2. In the **Connection Factory** section, set the **Factory configuration** field to **Edit inline**. 3. Select the **Trusted packages** field. 4. Click the plus sign to add a new package. 5. In the **Trusted package** window, set the **Value** field to `com.mulesoft.someapp`. 6. Click **Finish**. 7. Repeat Step 4. 8. In the **Trusted package** window, set the **Value** field to `com.mulesoft.someapp.model`. 9. Click **Finish**. 10. Select the **Trust all packages** field. 11. Click **OK**. ![Select the Trusted packages and Trust all packages field](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-activemq-packages.png) Figure 4. JMS Connector Trusted Packages configuration In the XML editor, the `` and `trustAllPackages` configurations look like this: ```xml ``` ## Configure SSL Connections JMS Connector version 1.3.0 and later enables you to configure ActiveMQ connections with SSL configurations to establish secure and encrypted connections against the ActiveMQ broker: 1. In Studio, navigate to the **Global Elements** tab. 2. Click **Create**. 3. In the filter box type `jms` and select **JMS Config**. 4. Click **OK**. 5. In the **Connection** field select **ActiveMQ Connection**. 6. Navigate to the **TLS/SSL** tab. 7. In the **TLS Configuration** field, select **Edit Inline** 8. In the **Trust Store Configuration** section, set the following fields: - **Path**: `client.ts` - **Password**: `password` 9. In the **Key Store Configuration** section, set the following fields: - **Path**: `client.ks` - **Alias**: `client` - **Key Password**: `password` - **Password**: `password` 10. Click **OK**. ![SSL Configuration.](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-activemq-ssl.png) Figure 5. JMS Connector SSK Configuration In the XML editor, the ``, ``, and `` configuration looks like this: ```xml ``` JMS Connector can also reference global TLS context configurations to reuse and share the same TLS context between connectors as shown in the following example with Anypoint Connector for HTTP (HTTP Connector): ```xml ``` ## See Also - [JMS Connector Reference](https://docs.mulesoft.com/jms-connector/1.10/jms-connector-reference) --- product: JMS Connector version: 2.0 is-latest-version: true keywords: jms, connector, jms_1.0.2b, jms_1.1, jms_2.0, activemq --- # Configure an ActiveMQ Connection for JMS Connector > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Connector for JMS (JMS Connector) includes an ActiveMQ connection configuration, which provides support for ActiveMQ 5. Using this connection, you can set JMS 1.1 (default), JMS 1.0.2b, or JMS 2.0 specifications, and you can configure not only all of the general connection parameters for JMS but also the custom parameters that are present only in ActiveMQ. ## Configure an ActiveMQ Connection After you declare the ActiveMQ connection, customize **Connection Factory** to your desired configuration. Every parameter in the connection comes with a default value, meaning that you are required to configure only the parameters relevant for your use case. Also, the ActiveMQ connection exposes parameters that are exclusive to the ActiveMQ implementation, like **Initial redelivery delay**. In the following example, you configure an **ActiveMQ Connection**: 1. In Studio, navigate to the **Global Elements** tab. 2. Click **Create**. 3. In the filter box type `jms` and select **JMS Config**. 4. Click **OK**. 5. In the **Connection** field select **ActiveMQ Connection**. 6. In the **Factory configuration** field, select **Edit Inline**. 7. Set the **Broker url** field value to the address of the broker to connect to, for example, `tcp://localhost:61616`. 8. Click **OK**. ![ActiveMQ Connection Configuration window in Studio with Broker URL field set to tcp://localhost:61616](/mulesoft/current/en-us/jms-connector/latest/_images/jms-activemq-configuration.png) In the XML editor, the `` and `` configuration looks like this: ```xml ``` ## Configure an ActiveMQ XA Connection Use **ActiveMQ XA Connection** to configure a connection that participates in Extended Architecture Transactions (XA transactions). This connection type is dedicated to XA scenarios and requires Mule runtime 4.10.0 or later. If you previously enabled XA on an **ActiveMQ Connection**, migrate to **ActiveMQ XA Connection** as described in [Upgrading and Migrating JMS Connector](https://docs.mulesoft.com/jms-connector/latest/jms-connector-upgrade-migrate). In the following example, you configure an **ActiveMQ XA Connection**: 1. In Studio, navigate to the **Global Elements** tab. 2. Click **Create**. 3. In the filter box type `jms` and select **JMS Config**. 4. Click **OK**. 5. In the **Connection** field select **ActiveMQ XA Connection**. 6. In the **Factory configuration** field, select **Edit Inline**. 7. Set the **Broker url** field value to the address of the broker to connect to, for example, `tcp://localhost:61616`. 8. In the **Advanced** tab, optionally configure the **XA connection pool** fields for **Max pool size** and **Max idle seconds**. 9. Click **OK**. In the XML editor, the `` and `` configuration looks like this: ```xml ``` For a complete example of how to use this connection type with XA transactions, see [Configuring XA Transactions in JMS Connector](https://docs.mulesoft.com/jms-connector/latest/jms-xa-transactions). ## Configure the Required Libraries When you configure any connection type, you must always configure a library containing the JMS client implementation, because JMS Connector is not bound to any particular implementation. Configure ActiveMQ external libraries in the global elements view of Studio or manually add the library dependency in your `pom.xml` file. These libraries are required for both ActiveMQ connection types, **ActiveMQ Connection** and **ActiveMQ XA Connection**. - **ActiveMQ KahaDB** The `activemq-kahadb-store` dependency is required only when using an persistent in-memory broker based on the VM transport (such as `vm://localhost?broker.persistent=true`). This dependency provides a valid `org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter` implementation. This dependency is also required for persistent message delivery. In your `pom.xml` file in Studio, adding the dependency looks like this: ```xml org.apache.activemq activemq-kahadb-store 5.14.4 ``` - **ActiveMQ Broker** The `activemq-broker` dependency is required only when using an in-memory broker based on the VM transport (which is the one configured by default). This dependency provides a valid `org.apache.activemq.broker.Broker` implementation. In your `pom.xml` file in Studio, adding the dependency looks like this: ```xml org.apache.activemq activemq-broker 5.14.4 ``` - **ActiveMQ Client** The `activemq-client` dependency is always required to use ActiveMQ connections. Choose one that provides a valid `org.apache.activemq.ActiveMQConnectionFactory` implementation. In your `pom.xml` file in Studio, adding the dependency looks like this: - ```xml org.apache.activemq activemq-client 5.14.4 ``` To configure these libraries in the Global Element view, follow these steps: 1. In Studio, navigate to the **Global Elements** tab. 2. Click **Create**. 3. In the filter box, type `jms` and select **JMS Config**. 4. Click **OK**. 5. In the **Connection** field, select **ActiveMQ Connection**. 6. In the **Required Libraries** section that shows the **ActiveMQ KahaDB**, **ActiveMQ Broker** and **ActiveMQ Client** libraries, click the **Configure…​** button to install the dependency. 7. Select any of the following install options: - **Add recommended library** Installs the recommended library. - **Use local file** Browse to a local file for the required engine library and install it. - **Add Maven dependency** Browse to the dependency and install it. ![Click the Configure button to install the dependencies](/mulesoft/current/en-us/jms-connector/latest/_images/jms-activemq-libaries.png) Figure 1. JMS Connector Libraries configuration ## Configure the In-Memory Broker By default, Anypoint Connector for ActiveMQ (ActiveMQ Connector) uses an in-memory broker, which makes it easy to start building an application without configuring a connection against an external broker. The in-memory broker is required to configure both the **ActiveMQ KahaDB** and **ActiveMQ Broker** libraries. The default URL is: `vm://localhost?broker.persistent=false&broker.useJmx=false` To configure the in-memory broker in Studio, follow these steps: 1. In Studio, open the **JMS Config** global element window. 2. In the **Connection Factory** section, set the **Factory configuration** field to **Edit inline**. 3. Set the **Broker url** field to the address of the broker to connect, for example, `vm://localhost?broker.persistent=false&broker.useJmx=false` . 4. Click **OK**. ![Set the Broker url field to the address of the broker to connect](/mulesoft/current/en-us/jms-connector/latest/_images/jms-activemq-broker.png) Figure 2. JMS Connector In-Memory Broker Configuration In the XML editor, the `brokerUrl` configuration looks like this: ```xml ``` ## Configure Message Redelivery When a message cannot be processed correctly, it’s not acknowledged. The message is then redelivered and probably again not processed correctly, which causes the cycle to execute indefinitely. To prevent a message from endless redelivery, configure the **Max redelivery** field. By default, JMS Connector uses a maximum redelivery value of `0`, which means that messages won’t be redelivered, regardless of whether the message is recovered or rolled back from a transaction. If the message has persistent delivery set, ActiveMQ sends the message to a `DLQ.QUEUE` (a dead letter queue). ActiveMQ also enables you to configure a client-side redelivery. - The **Initial redelivery delay** field enables you to configure, in milliseconds, how much time to wait before the first message redelivers. - The **Redelivery delay** field enables you to configure, in milliseconds, how much time to wait until the message is subsequently redelivered after the first redelivery. To configure these fields in Studio, follow these steps: 1. In Studio, open the **JMS Config** global element window. 2. In the **Connection Factory** section, set the **Factory configuration** field to **Edit inline**. 3. Set the **Initial redelivery delay** field to `1000`. 4. Set the **Redelivery delay** field to `100`. 5. Set the **Max redelivery** field to `10`. 6. Click **OK**. ![Set the Max redelivery field to 10](/mulesoft/current/en-us/jms-connector/latest/_images/jms-activemq-redelivery.png) Figure 3. JMS Connector Redelivery configuration In the XML editor, the `maxRedelivery`,`redeliveryDelay`, and `initialRedeliveryDelay` configurations look like this: ```xml ``` ## Configure Trusted Packages ActiveMQ versions 5.12.2, 5.13.0, and later restrict the classes that can be serialized and deserialized, helping to prevent the execution of a malicious payload on the host system. For ActiveMQ, JMS Connector enables by default only the JDK and JRE provided classes, so if you need to exchange object messages, you must add the packages your applications use by activating the **Trusted packages** field. Even though you can also enable the **Trust all packages** field to allow the serialization of more classes by allowing any object to be serialized and deserialized, this is not as secure as leaving it disabled in most cases. Keep this parameter disabled to improve the security and help prevent malicious attacks. In the following example, you configure the connection to enable only users who are compliant with the `com.mulesoft.someapp` and `com.mulesoft.someapp.model` packages to consume and produce ObjectMessages: 1. In Studio, open the **JMS Config** global element window. 2. In the **Connection Factory** section, set the **Factory configuration** field to **Edit inline**. 3. Select the **Trusted packages** field. 4. Click the plus sign to add a new package. 5. In the **Trusted package** window, set the **Value** field to `com.mulesoft.someapp`. 6. Click **Finish**. 7. Repeat Step 4. 8. In the **Trusted package** window, set the **Value** field to `com.mulesoft.someapp.model`. 9. Click **Finish**. 10. Select the **Trust all packages** field. 11. Click **OK**. ![Select the Trusted packages and Trust all packages field](/mulesoft/current/en-us/jms-connector/latest/_images/jms-activemq-packages.png) Figure 4. JMS Connector Trusted Packages configuration In the XML editor, the `` and `trustAllPackages` configurations look like this: ```xml ``` ## Configure SSL Connections JMS Connector version 1.3.0 and later enables you to configure ActiveMQ connections with SSL configurations to establish secure and encrypted connections against the ActiveMQ broker: 1. In Studio, navigate to the **Global Elements** tab. 2. Click **Create**. 3. In the filter box type `jms` and select **JMS Config**. 4. Click **OK**. 5. In the **Connection** field select **ActiveMQ Connection**. 6. Navigate to the **TLS/SSL** tab. 7. In the **TLS Configuration** field, select **Edit Inline** 8. In the **Trust Store Configuration** section, set the following fields: - **Path**: `client.ts` - **Password**: `password` 9. In the **Key Store Configuration** section, set the following fields: - **Path**: `client.ks` - **Alias**: `client` - **Key Password**: `password` - **Password**: `password` 10. Click **OK**. ![SSL Configuration.](/mulesoft/current/en-us/jms-connector/latest/_images/jms-activemq-ssl.png) Figure 5. JMS Connector SSK Configuration In the XML editor, the ``, ``, and `` configuration looks like this: ```xml ``` JMS Connector can also reference global TLS context configurations to reuse and share the same TLS context between connectors as shown in the following example with Anypoint Connector for HTTP (HTTP Connector): ```xml ``` ## See Also - [Configuring XA Transactions in JMS Connector](https://docs.mulesoft.com/jms-connector/latest/jms-xa-transactions) - [Upgrading and Migrating JMS Connector](https://docs.mulesoft.com/jms-connector/latest/jms-connector-upgrade-migrate) - [JMS Connector Reference](https://docs.mulesoft.com/jms-connector/latest/jms-connector-reference) --- product: JMS Connector version: 1.10 keywords: jms, connector, consume, message, ack --- # Configure Message Acknowledgement with the JMS Connector > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Connector for JMS (JMS Connector) provides different message acknowledgement modes to configure for the **Ack**, **Consume**, **On New Message**, and **Recovery session** operations: - Automatic acknowledgement on success - Immediate acknowledgement - Manual acknowledgement The following examples illustrate how to configure each message acknowledgement mode. ## Configure Automatic Acknowledgement on Success Mode Configure the automatic acknowledgement on success mode in the **On New Message** source by setting the **Acknowledge Mode** field to either one of these modes: - **AUTO** Automatically acknowledges (ACK) the received message only if the flow execution completes successfully; otherwise, the message is not acknowledged and is redelivered. - **DUPS\_OK** Like **AUTO** mode, automatically acknowledges (ACK) the received message only if the flow execution completes successfully, but leads to duplicate messages if the message is redelivered before the ACK is performed. In the following example, you configure the **AUTO** acknowledgement mode: 1. In Studio, select the **On New Message** source from your flow. 2. In the **On New Message** configuration screen, in **Destination**, specify the name of the destination from which to consume the message, for example, `#[vars.destination]`. 3. From the **Acknowledge Mode** menu, select **AUTO**. ![In the On New Message source screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-ack-auto.png) Figure 1. JMS Connector Auto Acknowledgement Mode configuration In the XML editor, the `` and `ackMode` configurations look like this: ```xml ``` ## Configure Immediate Acknowledgement Mode Configure the immediate acknowledgement mode in the **On New Message** source by using the **Acknowledge Mode** field, or in the **Consume** operation by using the **Ack mode** field. Set the fields to **IMMEDIATE**. This mode automatically acknowledges (ACK) the message after it is consumed and before to any application processing of the message. The result of automatically acknowledging the message is that the message won’t be redelivered if any error occurs during message processing, requiring application logic like a "dead letter" queue to manage errors without losing messages. In the following example, you configure the **IMMEDIATE** acknowledgement mode for the **Consume** operation: 1. In Studio, select the **Consume** operation from your flow. 2. In the **Consume** configuration screen, in **Destination**, specify the name of the destination from which to consume the message, for example, `#[vars.destination]`. 3. From the **Ack mode** menu, select **IMMEDIATE**. ![In the Consume operation screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-ack-immediate.png) Figure 2. JMS Connector Immediate Acknowledgement Mode configuration In the XML editor, the `` and `ackMode` configurations look like this: ## Configure Manual Acknowledgement Mode Configure the manual acknowledgement mode in the **On New Message** source by using the **Acknowledge Mode** field, or in the **Consume** operation by using the **Ack mode** field. Set these fields to **MANUAL**. This mode delegates all responsibility for performing message acknowledgement (ACK) to the application logic. Every message received by either the **On New Message** or **Consume** operations includes an acknowledgement ID in the Mule message attributes, that identifies the message uniquely for a given connection. The acknowledgement ID that identifies the message is then passed to the **Ack** operation in the **Ack id** field. In the following example, you configure the **MANUAL** acknowledgement mode for the **Consume** operation: 1. In Studio, select the **Consume** operation from your flow. 2. In the **Consume** configuration screen, in **Destination**, specify the name of the destination from which to consume the message, for example, `openTickets`. 3. From the **Ack mode** menu, select **MANUAL**. 4. Drag a **Logger** component to the right of the **Consume** operation. 5. Set the **Message** field to `#[payload]`. 6. Drag an **Ack** operation to the right of the **Logger** component. 7. Set the **Ack id** field to the acknowledgement ID of the message session to recover, for example, `#[attributes.ackId]`. ![In the Ack operation screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-ack-operation.png) Figure 3. JMS Connector Ack operation configuration In the XML editor, the ``, `ackMode`, and `ackId` configurations look like this: ```xml ``` ### Configure Manual Session Recovery With manual acknowledgement mode, all messages received but not acknowledged are not redelivered by the broker. If there is an error during the message processing, you must manually recover all the messages in the session that have to be redelivered by using the **Recover session** operation. The connection used to recover the session has to be the same as the connection for receiving the message. In the following example, you configure the **MANUAL** acknowledgement mode and how to recover the session: 1. In Studio, select the **Consume** operation from your flow. 2. In the **Consume** configuration screen, in **Destination**, specify the name of the destination from which to consume the message, for example, `${destination}`. 3. Set the **Ack mode** field to **MANUAL**. 4. Drag a **Logger** component to the right of the **Consume** operation. 5. Set the **Message** field to `#[payload]`. 6. Drag an **Ack** operation to the right of the **Logger** component. 7. Set the **Ack id** field to the acknowledgement ID of the message session to recover, for example, `#[vars.consumedMessage.attributes.ackId]`. 8. In your flow, expand the **Error handling** section by clicking the small arrow. 9. Drag an **On Error Propagate** component in the **Error handling** section. 10. Drag a **Recover session** operation inside the **On Error Propagate** component. 11. Set the **Ack id** field to `#[vars.consumedMessage.attributes.ackId]`. ![In the Recover session operation screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-ack-recover.png) Figure 4. JMS Connector Recover session operation configuration In the XML editor, the ``, `ackMode`, and `ackId` configurations look like this: ```xml ``` ## See Also - [Configure Topic Subscriptions](https://docs.mulesoft.com/jms-connector/1.10/jms-topic-subscription) - [Listen for New Messages](https://docs.mulesoft.com/jms-connector/1.10/jms-listener) --- product: JMS Connector version: 2.0 is-latest-version: true keywords: jms, connector, consume, message, ack --- # Configure Message Acknowledgement with the JMS Connector > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Connector for JMS (JMS Connector) provides different message acknowledgement modes to configure for the **Ack**, **Consume**, **On New Message**, and **Recovery session** operations: - Automatic acknowledgement on success - Immediate acknowledgement - Manual acknowledgement The following examples illustrate how to configure each message acknowledgement mode. ## Configure Automatic Acknowledgement on Success Mode Configure the automatic acknowledgement on success mode in the **On New Message** source by setting the **Acknowledge Mode** field to either one of these modes: - **AUTO** Automatically acknowledges (ACK) the received message only if the flow execution completes successfully; otherwise, the message is not acknowledged and is redelivered. - **DUPS\_OK** Like **AUTO** mode, automatically acknowledges (ACK) the received message only if the flow execution completes successfully, but leads to duplicate messages if the message is redelivered before the ACK is performed. In the following example, you configure the **AUTO** acknowledgement mode: 1. In Studio, select the **On New Message** source from your flow. 2. In the **On New Message** configuration screen, in **Destination**, specify the name of the destination from which to consume the message, for example, `#[vars.destination]`. 3. From the **Acknowledge Mode** menu, select **AUTO**. ![In the On New Message source screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-ack-auto.png) Figure 1. JMS Connector Auto Acknowledgement Mode configuration In the XML editor, the `` and `ackMode` configurations look like this: ```xml ``` ## Configure Immediate Acknowledgement Mode Configure the immediate acknowledgement mode in the **On New Message** source by using the **Acknowledge Mode** field, or in the **Consume** operation by using the **Ack mode** field. Set the fields to **IMMEDIATE**. This mode automatically acknowledges (ACK) the message after it is consumed and before to any application processing of the message. The result of automatically acknowledging the message is that the message won’t be redelivered if any error occurs during message processing, requiring application logic like a "dead letter" queue to manage errors without losing messages. In the following example, you configure the **IMMEDIATE** acknowledgement mode for the **Consume** operation: 1. In Studio, select the **Consume** operation from your flow. 2. In the **Consume** configuration screen, in **Destination**, specify the name of the destination from which to consume the message, for example, `#[vars.destination]`. 3. From the **Ack mode** menu, select **IMMEDIATE**. ![In the Consume operation screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-ack-immediate.png) Figure 2. JMS Connector Immediate Acknowledgement Mode configuration In the XML editor, the `` and `ackMode` configurations look like this: ## Configure Manual Acknowledgement Mode Configure the manual acknowledgement mode in the **On New Message** source by using the **Acknowledge Mode** field, or in the **Consume** operation by using the **Ack mode** field. Set these fields to **MANUAL**. This mode delegates all responsibility for performing message acknowledgement (ACK) to the application logic. Every message received by either the **On New Message** or **Consume** operations includes an acknowledgement ID in the Mule message attributes, that identifies the message uniquely for a given connection. The acknowledgement ID that identifies the message is then passed to the **Ack** operation in the **Ack id** field. In the following example, you configure the **MANUAL** acknowledgement mode for the **Consume** operation: 1. In Studio, select the **Consume** operation from your flow. 2. In the **Consume** configuration screen, in **Destination**, specify the name of the destination from which to consume the message, for example, `openTickets`. 3. From the **Ack mode** menu, select **MANUAL**. 4. Drag a **Logger** component to the right of the **Consume** operation. 5. Set the **Message** field to `#[payload]`. 6. Drag an **Ack** operation to the right of the **Logger** component. 7. Set the **Ack id** field to the acknowledgement ID of the message session to recover, for example, `#[attributes.ackId]`. ![In the Ack operation screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-ack-operation.png) Figure 3. JMS Connector Ack operation configuration In the XML editor, the ``, `ackMode`, and `ackId` configurations look like this: ```xml ``` ### Configure Manual Session Recovery With manual acknowledgement mode, all messages received but not acknowledged are not redelivered by the broker. If there is an error during the message processing, you must manually recover all the messages in the session that have to be redelivered by using the **Recover session** operation. The connection used to recover the session has to be the same as the connection for receiving the message. In the following example, you configure the **MANUAL** acknowledgement mode and how to recover the session: 1. In Studio, select the **Consume** operation from your flow. 2. In the **Consume** configuration screen, in **Destination**, specify the name of the destination from which to consume the message, for example, `${destination}`. 3. Set the **Ack mode** field to **MANUAL**. 4. Drag a **Logger** component to the right of the **Consume** operation. 5. Set the **Message** field to `#[payload]`. 6. Drag an **Ack** operation to the right of the **Logger** component. 7. Set the **Ack id** field to the acknowledgement ID of the message session to recover, for example, `#[vars.consumedMessage.attributes.ackId]`. 8. In your flow, expand the **Error handling** section by clicking the small arrow. 9. Drag an **On Error Propagate** component in the **Error handling** section. 10. Drag a **Recover session** operation inside the **On Error Propagate** component. 11. Set the **Ack id** field to `#[vars.consumedMessage.attributes.ackId]`. ![In the Recover session operation screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-ack-recover.png) Figure 4. JMS Connector Recover session operation configuration In the XML editor, the ``, `ackMode`, and `ackId` configurations look like this: ```xml ``` ## See Also - [Configure Topic Subscriptions](https://docs.mulesoft.com/jms-connector/latest/jms-topic-subscription) - [Listen for New Messages](https://docs.mulesoft.com/jms-connector/latest/jms-listener) --- product: JMS Connector version: 1.10 keywords: jms, connector, consume, source, listener, topic, subscription --- # Configure Topic Subscriptions with JMS Connector > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Topic subscriptions in JMS enable you to configure how the subscription behaves regarding the connection of consumers and how consumers interact. The Anypoint Connector for JMS (JMS Connector) **Consumer** and **On New Message** operations manage topic subscriptions in the **Consumer type** field by selecting the **Topic consumer** configuration. ## Configure Durable Subscriptions Durable subscriptions enable you to receive messages published to the topic while the consumer is offline. The JMS provider stores messages sent or published to a topic, just as it would store messages sent to a queue. If another application has a **Topic consumer** configuration that uses the same connection, client ID, topic, and subscription name, the subscription reactivates, and the JMS provider delivers the published messages while the subscriber was inactive. In the following example, you **Topic consumer** to **Durable**: 1. In Studio, select the **Consume** operation from your flow. 2. Set the **Destination** field to `#[vars.destination]`. 3. Set the **Consumer type** field to **Topic consumer**. 4. Select the **Durable** option. 5. Set the **Subscription name** to `SampleSub`. ![In the Consume operation screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-topic-durable.png) Figure 1. JMS Connector Topic Consumer Durable configuration In the XML editor, the `` and `durable` configurations look like this: ```xml ``` ## Configure Shared Subscriptions In a JMS spec 1.1 connection, a subscription to a topic cannot have more than one consumer at a time, meaning that the processing work of messages on a topic subscription cannot be shared, thereby limiting the scalability of the application. The JMS spec 2.0 connection removes this restriction and enables you to configure shared consumers on the same subscription. In the following example, you set **Topic consumer** to **Shared**: 1. In Studio, select the **Consume** operation from your flow. 2. Set the **Destination** field to `InvoiceEventsTopic`. 3. Set the **Consumer type** field to **Topic consumer**: 4. Select the **Shared** option. 5. Set the **Subscription name** to `ClusterSubscription`. ![In the Consume operation screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-topic-shared.png) Figure 2. JMS Connector Topic Consumer Shared configuration In the XML editor, the `` and `shared` configurations look like this: ```xml ``` ## Configure No Local Subscriptions There are cases in which you may not want to receive published messages to a topic by the same application. To prevent the consumer to receive published messages to a topic by the same connection, configure the **Topic consumer** field to **No local**. Consumers configured as no local can not be part of a shared subscription. In the following example, you set **Topic consumer** to **No local** : 1. In Studio, select the **Consume** operation from your flow. 2. Set the **Destination** field to `{notificationsChannel}`. 3. Set the **Consumer type** field to **Topic consumer**: 4. Select the **No local** option. ![In the Consume operation screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-topic-nolocal.png) Figure 3. JMS Connector Topic Consumer No local configuration In the XML editor, the `` and `noLocal` configurations look like this: ```xml ``` ## See Also - [Listen for New Messages](https://docs.mulesoft.com/jms-connector/1.10/jms-listener) - [Consume Messages](https://docs.mulesoft.com/jms-connector/1.10/jms-consume) --- product: JMS Connector version: 2.0 is-latest-version: true keywords: jms, connector, consume, source, listener, topic, subscription --- # Configure Topic Subscriptions with JMS Connector > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Topic subscriptions in JMS enable you to configure how the subscription behaves regarding the connection of consumers and how consumers interact. The Anypoint Connector for JMS (JMS Connector) **Consumer** and **On New Message** operations manage topic subscriptions in the **Consumer type** field by selecting the **Topic consumer** configuration. ## Configure Durable Subscriptions Durable subscriptions enable you to receive messages published to the topic while the consumer is offline. The JMS provider stores messages sent or published to a topic, just as it would store messages sent to a queue. If another application has a **Topic consumer** configuration that uses the same connection, client ID, topic, and subscription name, the subscription reactivates, and the JMS provider delivers the published messages while the subscriber was inactive. In the following example, you **Topic consumer** to **Durable**: 1. In Studio, select the **Consume** operation from your flow. 2. Set the **Destination** field to `#[vars.destination]`. 3. Set the **Consumer type** field to **Topic consumer**. 4. Select the **Durable** option. 5. Set the **Subscription name** to `SampleSub`. ![In the Consume operation screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-topic-durable.png) Figure 1. JMS Connector Topic Consumer Durable configuration In the XML editor, the `` and `durable` configurations look like this: ```xml ``` ## Configure Shared Subscriptions In a JMS spec 1.1 connection, a subscription to a topic cannot have more than one consumer at a time, meaning that the processing work of messages on a topic subscription cannot be shared, thereby limiting the scalability of the application. The JMS spec 2.0 connection removes this restriction and enables you to configure shared consumers on the same subscription. In the following example, you set **Topic consumer** to **Shared**: 1. In Studio, select the **Consume** operation from your flow. 2. Set the **Destination** field to `InvoiceEventsTopic`. 3. Set the **Consumer type** field to **Topic consumer**: 4. Select the **Shared** option. 5. Set the **Subscription name** to `ClusterSubscription`. ![In the Consume operation screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-topic-shared.png) Figure 2. JMS Connector Topic Consumer Shared configuration In the XML editor, the `` and `shared` configurations look like this: ```xml ``` ## Configure No Local Subscriptions There are cases in which you may not want to receive published messages to a topic by the same application. To prevent the consumer to receive published messages to a topic by the same connection, configure the **Topic consumer** field to **No local**. Consumers configured as no local can not be part of a shared subscription. In the following example, you set **Topic consumer** to **No local** : 1. In Studio, select the **Consume** operation from your flow. 2. Set the **Destination** field to `{notificationsChannel}`. 3. Set the **Consumer type** field to **Topic consumer**: 4. Select the **No local** option. ![In the Consume operation screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-topic-nolocal.png) Figure 3. JMS Connector Topic Consumer No local configuration In the XML editor, the `` and `noLocal` configurations look like this: ```xml ``` ## See Also - [Listen for New Messages](https://docs.mulesoft.com/jms-connector/latest/jms-listener) - [Consume Messages](https://docs.mulesoft.com/jms-connector/latest/jms-consume) --- product: JMS Connector version: 1.2 keywords: jms, connector, jms_1.0.2b, jms_1.1, jms_2.0, activemq --- # Configuring an ActiveMQ Connection > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Connector for JMS (JMS Connector) includes an ActiveMQ connection configuration, which provides out-of-the-box support for ActiveMQ 5. With this connection, you can use JMS 1.1 (default), JMS 1.0.2b, or JMS 2.0 specifications, and you can configure not only all of the general connection parameters for JMS but also the custom parameters that are present only in ActiveMQ. ## Connecting to ActiveMQ After you declare `active-mq-connection`, all you need to do is set up the connection factory with your custom configuration. Every parameter in the connection comes with a default value, meaning that you are required to configure only the parameters relevant for your use case. The ActiveMQ connection also exposes parameters that are exclusive to ActiveMQ implementation, like `initialRedeliveryDelay`. The following example shows a simple configuration of an ActiveMQ connection: ```xml ``` ## In-Memory Broker By default, Anypoint Connector for ActiveMQ (ActiveMQ Connector) uses an in-memory broker, which makes it easy to start building an application without configuring a connection against an external broker. Default URL: `vm://localhost?broker.persistent=false&broker.useJmx=false` The in-memory broker is required to configure both the [ActiveMQ Client](#activemq-client-lib) and [ActiveMQ Broker](#activemq-broker-lib) libraries. ## SSL Connections This information applies to JMS Connector version 1.3.0 and later. You can configure ActiveMQ connections with SSL configurations to enable the connector to establish secure and encrypted connections against the ActiveMQ broker: ```xml ``` ![JMS ActiveMQ SSL Configuration](/mulesoft/current/en-us/jms-connector/1.2/_images/jms-ssl.png) The connector can also reference global TLS context configurations, so you can reuse and share the same TLS context between connectors as shown in the following example with Anypoint Connector for HTTP (HTTP Connector): ```xml ``` ## Delivery Handling ### Avoiding Poison Messages When a message cannot be processed correctly, it’s not acknowledged. The message is then redelivered and probably again not processed correctly, which can cause the cycle to execute indefinitely. To prevent a message that can’t be properly handled from endlessly redelivering ("poison messages"), you can configure the `maxRedelivery` parameter to set a maximum number of times that a message can be delivered to the application. In this example a message is redelivered a maximum of 10 times: ```xml ``` By default, JMS Connector uses a `maxRedelivery` of `0`, which means that messages won’t be redelivered, and it doesn’t matter if the message is recovered or rolled back from a transaction. If the message has persistent delivery set, ActiveMQ sends the message to `DLQ.QUEUE` (dead letter queue). ### Advanced Redelivery ActiveMQ enables users to have a client-side redelivery configuration. You can also configure the [maximum times that a message is redelivered](#poison-messages) and how fast the connector is required to redeliver the message. `initialRedeliveryDelay`: In milliseconds, how much time to wait for the message to be redelivered the first time. `redeliveryDelay`: In milliseconds, how much time to wait until the message is subsequently redelivered after the first redelivery. ```xml ``` ## Object Serialization ActiveMQ 5.12.2, 5.13.0, and later restricts the classes that can be serialized and deserialized to prevent the execution of a malicious payload that can exploit the host system. ### Trusted Packages For ActiveMQ, JMS Connector allows only the JDK and JRE provided classes by default, so if you need to exchange object messages, you must add the packages your applications are using: ```xml ``` ![JMS ActiveMQ Trusted Packages](/mulesoft/current/en-us/jms-connector/1.2/_images/jms-trusted-packages.png) In the previous example, JMS Connector allows only users who are compliant with the `com.mulesoft.someapp` and `com.mulesoft.someapp.model` packages to consume and produce ObjectMessages. ### Trust All Packages Even though you can enable the **Trust All Packages** parameter to allow the serialization of more classes by allowing any object to be serialized and deserialized, this is not as secure as leaving it disabled in most cases. Keep this parameter disabled (`false`) to improve security and help prevent malicious attacks. ```xml ``` ## Configuring Required Libraries ![Configuring Required JMS Libraries](/mulesoft/current/en-us/jms-connector/1.2/_images/jms-libs.gif) ### ActiveMQ Client The ActiveMQ client library is the only library that is required to use ActiveMQ connections. The ActiveMQ client library is also needed to connect to a broker. ```xml org.apache.activemq activemq-client 5.15.4 ``` ### ActiveMQ Broker The ActiveMQ broker can create an [In Memory Broker](#in-memory-broker): ```xml org.apache.activemq activemq-broker 5.15.4 ``` ### ActiveMQ KahaDB The ActiveMQ KahaDB is required when using an [In Memory Broker](#in-memory-broker) and is also required for persistent message delivery. ```xml org.apache.activemq activemq-kahadb-store 5.15.4 ``` ## See Also - [How to Consume Messages](https://docs.mulesoft.com/jms-connector/1.2/jms-consume) - [How to Publish Messages](https://docs.mulesoft.com/jms-connector/1.2/jms-publish) - [How to Listen For New Messages](https://docs.mulesoft.com/jms-connector/1.2/jms-listener) - [How to Listen For A Reply](https://docs.mulesoft.com/jms-connector/1.2/jms-publish-consume) - [Handling Message Acknowledgement](https://docs.mulesoft.com/jms-connector/1.2/jms-ack) - [Handling Transactions in JMS](https://docs.mulesoft.com/jms-connector/1.2/jms-transactions) - [JMS Tuning For Performance](https://docs.mulesoft.com/jms-connector/1.2/jms-performance) --- product: JMS Connector version: 1.10 --- # Configuring XA Transactions in JMS Connector > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Connector for JMS (JMS Connector) provides the option to use Extended Architecture Transactions (XA Transactions) when you configure the **XA Connection Pool** and the **Transaction Type** fields. ## Before You Begin Before getting started, ensure that you have an understanding of [XA Transactions](https://docs.mulesoft.com/mule-runtime/latest/xa-transactions). ## Configure XA Transactions To configure XA transactions, follow these steps: 1. In your **JMS Config**, configure the **XA Connection Pool** fields for **Min pool size**, **Max pool size**, and **Max idle seconds**: ```xml ``` 2. Configure the **JMS Listener** source **XA Transaction** field to `XA`: ```xml ``` In the **Configuration XML** editor window, the Mule app configuration looks like this: ```xml ``` ## See Also [JMS Connector Examples](https://docs.mulesoft.com/jms-connector/1.10/jms-examples) --- product: JMS Connector version: 2.0 is-latest-version: true --- # Configuring XA Transactions in JMS Connector > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Connector for JMS (JMS Connector) provides the option to use Extended Architecture Transactions (XA Transactions) when you configure the **ActiveMQ XA Connection** connection type and the **Transaction Type** fields. From JMS Connector 2.0 onward, and requiring Mule runtime 4.10.0 or later, XA transactions are configured using a dedicated XA connection type instead of enabling XA on a standard connection. Depending on your broker implementation, select **ActiveMQ XA Connection** or **Generic XA Connection**. If you are upgrading from an earlier version of the connector, see [Upgrading and Migrating JMS Connector](https://docs.mulesoft.com/jms-connector/latest/jms-connector-upgrade-migrate). ## Before You Begin Before getting started, ensure that you have an understanding of [XA Transactions](https://docs.mulesoft.com/mule-runtime/latest/xa-transactions). ## Configure XA Transactions To configure XA transactions, follow these steps: 1. In your **JMS Config**, select the **ActiveMQ XA Connection** connection type, and configure the **XA Connection Pool** fields for **Max pool size** and **Max idle seconds**: ```xml ``` 2. Configure the **JMS Listener** source **XA Transaction** field to `XA`: ```xml ``` In the **Configuration XML** editor window, the Mule app configuration looks like this: ```xml ``` ## See Also - [JMS Connector Examples](https://docs.mulesoft.com/jms-connector/latest/jms-examples) - [Configure an ActiveMQ Connection for JMS Connector](https://docs.mulesoft.com/jms-connector/latest/jms-activemq-configuration) - [Upgrading and Migrating JMS Connector](https://docs.mulesoft.com/jms-connector/latest/jms-connector-upgrade-migrate) --- product: JMS Connector version: 1.10 keywords: jms, connector, consume, message --- # Consume Messages with the JMS Connector > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Connector for JMS (JMS Connector) **Consume** operation enables you to consume a message at any time in the flow, from any given specified destination. ## Consume a Message from a Queue In the following example, you configure the **Consume** operation to consume new messages in the queue specified in the **Destination** field. The operation returns a Mule message each time a JMS message is available in the queue. The Mule message consists of: - The message content as payload - The message metadata in the message attributes The metadata has three parts that map all the information available in a JMS message: - AckId - Headers - Properties By default, the message consumed is acknowledged ("ACKed") only when the execution of the flow receiving the message completes successfully. If you want to control the ACK of the message after some processing, configure the `ackMode` to `MANUAL`. For more information regarding a Message ACK, review the [Manage Message Acknowledgement](https://docs.mulesoft.com/jms-connector/1.10/jms-ack) documentation. To configure the source in Studio, follow these steps: 1. In the **Mule Palette** view, select **JMS > Consume**. 2. Drag **Consume** to the Studio canvas. 3. In the **Consume** configuration screen, optionally change the value of the **Display Name** field. 4. In the **Consume** configuration screen, in **Destination**, specify the name of the destination from which to consume the message, for example, `#[vars.destination]`. ![In the Consume operation screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-consume-queue.png) Figure 1. JMS Connector Consume configuration In the XML editor, the `` configuration looks like this: ```xml ``` ## Consume a Message from a Topic Subscription In the following example, you configure the **Consume** operation to consume new messages from a topic subscription by setting the **Consumer type** field to **Topic consumer**. To configure the source in Studio, follow these steps: 1. In the **Mule Palette** view, select **JMS > Consume**. 2. Drag **Consume** to the Studio canvas. 3. In the **Consume** configuration screen, optionally change the value of the **Display Name** field. 4. In the **Consume** configuration screen, in **Destination**, specify the name of the destination from which to consume the message for example `#[vars.destination]`. 5. Set the **Consumer type** field to **Topic consumer**: ![In the Consume operation screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-consume-topic.png) Figure 2. JMS Connector Consume on Topic subscription configuration In the XML editor, the `` and `` configuration looks like this: ```xml ``` ## Wait for a Message By default, the **Consume** operation waits for a message for up to 10000 milliseconds, after which you receive the error `JMS:TIMEOUT`. To better suit your use case, configure the **Maximum wait** and **Maximum wait unit** fields. To wait indefinitely for a message to arrive, set the **Maximum wait** field to `-1`, which prevents a `JMS:TIMEOUT` error. ## Poll for a Message When polling for a message with a certain frequency, you don’t want the consumer to block waiting for the message, but instead just try to consume it if one is present. In this case, set the **Maximum wait** field to `0`, which indicates that no waiting occurs, and neither an error is thrown if no message is available in the specified destination. The output of the **Consume** operation is `null` when no message is present for consumption and no error is thrown. ## Filter Incoming Messages JMS Connector supports filtering messages to consume based on the standard JMS selector language you specify in the **Selector** field of the **Consume** operation. By doing so, you receive only the messages matching the selector language, ignoring any other messages in the destination. In the following example, you configure a priority queue that processes messages faster than others queues: 1. In Studio, select the **Consume** operation from your flow. 2. Set the **Destination** field to `openTickets`. 3. Set the **Selector** field to `JMSPriority=8`: JMS Connector On New Message Filtering messages image::jms-consume-selector.png\[In the Consume operation screen, set the Selector field to filter incoming messages\] In the XML editor, the `selector` configuration looks like this: ```xml ``` ## Configure Mime Types and Encoding JMS Connector determines a message’s mime type (`contentType`) based on the `MM_MESSAGE_CONTENT_TYPE` property. However, when you must manage the message’s content, configure the **Content-Type** field to the particular content type value you need. By default, JMS Connector assumes that Mule runtime engine default encoding matches the encoding in the message if no other information is provided. Use the **Encoding** field to configure a different type of encoding. In the following example, you configure the content-type and encoding: 1. In Studio, select the **Consume** operation from your flow. 2. Set the **Content-Type** field to `application/JSON`. 3. Set the **Encoding** field to `UTF-8`. ![In the Consume operation screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-consume-types-encoding.png) Figure 3. JMS Connector Consume Content-Type and Encoding In the XML editor, the `contentType` and `encoding` configuration looks like this: ```xml ``` ## See Also - [Configure Topic Subscriptions](https://docs.mulesoft.com/jms-connector/1.10/jms-topic-subscription) - [Listen For New Messages](https://docs.mulesoft.com/jms-connector/1.10/jms-listener) - [Troubleshoot Prefetch Issues](https://docs.mulesoft.com/jms-connector/1.10/jms-troubleshooting#prefetch-issues) --- product: JMS Connector version: 2.0 is-latest-version: true keywords: jms, connector, consume, message --- # Consume Messages with the JMS Connector > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Connector for JMS (JMS Connector) **Consume** operation enables you to consume a message at any time in the flow, from any given specified destination. ## Consume a Message from a Queue In the following example, you configure the **Consume** operation to consume new messages in the queue specified in the **Destination** field. The operation returns a Mule message each time a JMS message is available in the queue. The Mule message consists of: - The message content as payload - The message metadata in the message attributes The metadata has three parts that map all the information available in a JMS message: - AckId - Headers - Properties By default, the message consumed is acknowledged ("ACKed") only when the execution of the flow receiving the message completes successfully. If you want to control the ACK of the message after some processing, configure the `ackMode` to `MANUAL`. For more information regarding a Message ACK, review the [Manage Message Acknowledgement](https://docs.mulesoft.com/jms-connector/latest/jms-ack) documentation. To configure the source in Studio, follow these steps: 1. In the **Mule Palette** view, select **JMS > Consume**. 2. Drag **Consume** to the Studio canvas. 3. In the **Consume** configuration screen, optionally change the value of the **Display Name** field. 4. In the **Consume** configuration screen, in **Destination**, specify the name of the destination from which to consume the message, for example, `#[vars.destination]`. ![In the Consume operation screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-consume-queue.png) Figure 1. JMS Connector Consume configuration In the XML editor, the `` configuration looks like this: ```xml ``` ## Consume a Message from a Topic Subscription In the following example, you configure the **Consume** operation to consume new messages from a topic subscription by setting the **Consumer type** field to **Topic consumer**. To configure the source in Studio, follow these steps: 1. In the **Mule Palette** view, select **JMS > Consume**. 2. Drag **Consume** to the Studio canvas. 3. In the **Consume** configuration screen, optionally change the value of the **Display Name** field. 4. In the **Consume** configuration screen, in **Destination**, specify the name of the destination from which to consume the message for example `#[vars.destination]`. 5. Set the **Consumer type** field to **Topic consumer**: ![In the Consume operation screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-consume-topic.png) Figure 2. JMS Connector Consume on Topic subscription configuration In the XML editor, the `` and `` configuration looks like this: ```xml ``` ## Wait for a Message By default, the **Consume** operation waits for a message for up to 10000 milliseconds, after which you receive the error `JMS:TIMEOUT`. To better suit your use case, configure the **Maximum wait** and **Maximum wait unit** fields. To wait indefinitely for a message to arrive, set the **Maximum wait** field to `-1`, which prevents a `JMS:TIMEOUT` error. ## Poll for a Message When polling for a message with a certain frequency, you don’t want the consumer to block waiting for the message, but instead just try to consume it if one is present. In this case, set the **Maximum wait** field to `0`, which indicates that no waiting occurs, and neither an error is thrown if no message is available in the specified destination. The output of the **Consume** operation is `null` when no message is present for consumption and no error is thrown. ## Filter Incoming Messages JMS Connector supports filtering messages to consume based on the standard JMS selector language you specify in the **Selector** field of the **Consume** operation. By doing so, you receive only the messages matching the selector language, ignoring any other messages in the destination. In the following example, you configure a priority queue that processes messages faster than others queues: 1. In Studio, select the **Consume** operation from your flow. 2. Set the **Destination** field to `openTickets`. 3. Set the **Selector** field to `JMSPriority=8`: JMS Connector On New Message Filtering messages image::jms-consume-selector.png\[In the Consume operation screen, set the Selector field to filter incoming messages\] In the XML editor, the `selector` configuration looks like this: ```xml ``` ## Configure Mime Types and Encoding JMS Connector determines a message’s mime type (`contentType`) based on the `MM_MESSAGE_CONTENT_TYPE` property. However, when you must manage the message’s content, configure the **Content-Type** field to the particular content type value you need. By default, JMS Connector assumes that Mule runtime engine default encoding matches the encoding in the message if no other information is provided. Use the **Encoding** field to configure a different type of encoding. In the following example, you configure the content-type and encoding: 1. In Studio, select the **Consume** operation from your flow. 2. Set the **Content-Type** field to `application/JSON`. 3. Set the **Encoding** field to `UTF-8`. ![In the Consume operation screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-consume-types-encoding.png) Figure 3. JMS Connector Consume Content-Type and Encoding In the XML editor, the `contentType` and `encoding` configuration looks like this: ```xml ``` ## See Also - [Configure Topic Subscriptions](https://docs.mulesoft.com/jms-connector/latest/jms-topic-subscription) - [Listen For New Messages](https://docs.mulesoft.com/jms-connector/latest/jms-listener) - [Troubleshoot Prefetch Issues](https://docs.mulesoft.com/jms-connector/latest/jms-troubleshooting#prefetch-issues) --- 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 ``` ### 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 ``` 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) --- product: JMS Connector version: 1.2 keywords: jms, connector, transactions, transactional --- # Handling Transactions in JMS > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Transactional connections in JMS allow you to execute a series of operations that are actually performed only when the transaction is committed. This has two main scenarios: - Publishing a Message as part of a transaction: When performing a `publish`, the Message will be effectively sent to the destination once the transaction is **committed**. If for some reason the transaction fails and a **rollback** occurs, then the Message will never be sent. - Consuming a Message as part of a transaction: In case of consuming a Message, either with the `listener` or `consume`, the Message will be acknowledged **only after the transacion is committed**, and instead it will be returned to the destination for redelivery if the transaction is **rolledback**. The JMS Connector provides support for executing its operations in a transactional way OOTB using Mule’s `transactionalAction` configuration. In order to execute an operation as part of the transaction, we have the following two options. ## Processing New Messages With Transactional Session If you want a JMS Listener to use a transactional session when dispatching the messages, you should set the `transactionalAction` to 'ALWAYS\_BEGIN': ```xml ``` With this configuration, each new message will be processed in a transaction that is propagate to all the flow’s components and is committed once the flow execution is completed successfully. The transaction will be rolledback if the flow execution is completed with an error. By default, **other components** in the flow **will not join the transaction** created by the listener. In order to execute other operations using the listener’s transaction, you must declare them either with 'ALWAYS\_JOIN', or 'JOIN\_IF\_POSSIBLE'. ## Execute Operations As Part Of A Transaction To execute an operation like `publish` or `consume` as part of a transaction, we have to set the `transactionalAction` to 'ALWAYS\_JOIN', or 'JOIN\_IF\_POSSIBLE': This operations can join a transaction initiated by the listener: ```xml ``` Or they can join an scoped transaction: ```xml ``` --- product: JMS Connector version: 1.2 --- # JMS Connector > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Connector for JMS (JMS Connector) enables your app to do messaging using the JMS implementation of your choice. Its main features include: - Pub/Sub pattern support on any given destination. - Listen/Reply pattern support on any given destination. - Publish-Consume pattern support on any given destination, with fixed or temporary reply Queue. - Fully compliant with JMS 2.0, 1.1, and 1.0.2 specifications. Release Notes: [JMS Connector Release Notes](https://docs.mulesoft.com/release-notes/connector/connector-jms) Exchange: [JMS Connector](https://www.mulesoft.com/exchange/org.mule.connectors/mule-jms-connector/) ## POM File Information ```xml org.mule.connectors mule-jms-connector x.x.x mule-plugin ``` Replace `x.x.x` with the version that corresponds to the connector you are using. To specify a version, view [JMS Connector](https://www.mulesoft.com/exchange/org.mule.connectors/mule-jms-connector/) in Anypoint Exchange and click **Dependency Snippets**. ## Configure the Connector Out of the box, the JMS connector comes with a fine tuned set of default values, both for publishing and consuming messages. This means that the only requirement is for you to configure which connection should be used. This example sets a minimal connection to an in-memory ActiveMQ broker the JMS connector: ```xml ``` ### Define Global Defaults The JMS `config` allows you to define multiple parameters that will be used as a default while consuming or publishing messages. This way, you can define a global default behavior for all the operations associated the config and then override each parameter only in the operations that require a custom behavior. For example, we can define a default `selector` behavior when consuming a Message in any of the operations that are associated to this config, and also a default ```xml ``` In this case, every operation `consume` or `listener` associated to this config will use this `selector` by default, while every time we do a `publish` or `publish-consume`, the outgoing Message will have a TTL of 60 seconds. All of this properties can be overridden at operation level when required. Let’s say we need to `publish` a Message with a shorter TTL, we can do so using this config and overriding the parameter: ```xml ``` ## Connecting to a Broker A JMS connection is defined by a set of general parameters that apply for any connection, as well as particular configurations related to the actual broker implementation that’s going to be used. ### Select the JMS Spec > [!TIP] The main common parameter is the JMS `specification` used to select between all the > supported specs, which are `2.0`, `1.1`, and `1.0.2b`. This `specification` must be supported by > the broker implementation associated to this connection, otherwise the connection fails. > [!WARNING] Features available only in JMS `2.0` won’t work with any other `specification`. ### Provide Credentials For Authentication In order to do establish an authenticated connection, you need to configure the `username` and `password` in the `connection` element: ```xml ``` ### Configure Connections Caching In order to connect with a broker and execute the required operations, the JMS Connector creates multiple Sessions, Consumers and Producers that can be cached and reused in order to increase the performance of the application. Because of this capability, the JMS Connector allows you to configure which `caching-strategy` to use when creating new Connections, caching by default both Consumers and Producers and preserving as many instances as possible in memory at the same time. Customizing the cache configuration can be done directly in the connection declaration: ```xml ``` In the same way, you can completely disable the caching of Connections using the `no-caching` option: ```xml ``` > [!TIP] Disabling the sessions cache using the `no-caching` configuration is greatly discouraged > and is meant to be used in cases where a custom ConnectionFactory is used that already handles > it\`s own cache. ### Identify the Connection Client The purpose of client identifier is to associate a connection and its objects with a state maintained on behalf of the client by a provider, and it is **mandatory** for identifying an unshared durable subscription. ```xml ``` > [!WARNING] By definition, the client state identified by a `clientId` can be "in use" by only one > Connection at a time. ## Connect To ActiveMQ Support for ActiveMQ 5 is provided out of the box by the connector using the `active-mq-connection`. With this connection, you can use both JMS 1.1 (the default) or JMS 1.0.2b specs, and configure all the general connection parameters for JMS, as well as the custom parameters only present in ActiveMQ. Once we declare the `active-mq-connection`, all that\`s left to do is set up the connection factory with our custom configuration. Every parameter in the connection comes with a default value, meaning that you are required to configure only the parameters relevant for your use case. Also, the ActiveMQ connection exposes parameters that are exclusive of ActiveMQ implementation, like `initialRedeliveryDelay`. An example of a simple configuration of an ActiveMQ connection would be: ```xml ``` ## Use Different Brokers In cases where ActiveMQ 5 is not the chosen broker, we can use the `generic-connection` to declare a connection to any broker implementation. Out of the box, the connector provides a JNDI based connection factory builder that allows to configure the connection using JNDI in the context of the application. For example, if we want to connect with Artemis to use the JMS 2.0 spec, we could define our connection factory in this way: ```xml ``` If you have configured a JNDI context on the connector, you can also look up destinations via JNDI using the `lookupDestination` attribute, which provides three different configurations: - NEVER: No lookup is done and the destinations are created using the existing JMS session - TRY\_ALWAYS: First try to find the destination using JNDI, and in case it doesn’t exist, create it using the current JMS Session. - ALWAYS: If a queue/topic cannot be found via JNDI, fail with a `JMS:DESTINATION_NOT_FOUND` error For more information regarding the `generic-connection` or `jndi-connection-factory`, see the connector reference docs. ## Set Up the Connection Libraries > [!NOTE] No matter what type of connection you are using, you always need to configure a library > containing the JMS client implementation since the connector is not bound to any particular > implementation. ### ActiveMQ External Libraries For an ActiveMQ connection, there are three possible libraries that need to be configured depending on your connection settings: - ActiveMQ JMS Client Library: The `activemq-client` of your choice that provides a valid `org.apache.activemq.ActiveMQConnectionFactory` implementation. > [!WARNING] This dependency is always required. For example, you can use: ```xml org.apache.activemq activemq-client 5.14.5 ``` - ActiveMQ Broker Library: The `activemq-broker` is only required when using an in-memory broker based on the VM transport (which is the one configured by default). This dependency should provide a valid `org.apache.activemq.broker.Broker` implementation. For example, you can use: ```xml org.apache.activemq activemq-broker 5.14.5 ``` - ActiveMQ KahaDB Library: The `activemq-kahadb-store` is only required when using an persistent in-memory broker based on the VM transport (such as, `vm://localhost?broker.persistent=true`). This dependency provides a valid `org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter` implementation. For example, you can use: ```xml org.apache.activemq activemq-kahadb-store 5.14.5 ``` ### Generic External Libraries When using a `jms:generic-connection`, provide all the libraries that your ConnectionFactory and configuration of choice required. This will always depend on what are the implementations you choose, so be careful of adding all the dependencies to the application. A common use case for this would be using the JMS 2.0 spec, thus you need a generic connection with a different client library, like Apache Artemis: ```xml org.apache.activemq artemis-jms-client-all 2.13.0 ``` ## See Also - [Consume Messages](https://docs.mulesoft.com/jms-connector/1.2/jms-consume) - [Publish Messages](https://docs.mulesoft.com/jms-connector/1.2/jms-publish) - [Listen For New Messages](https://docs.mulesoft.com/jms-connector/1.2/jms-listener) - [Listen For A Reply](https://docs.mulesoft.com/jms-connector/1.2/jms-publish-consume) - [Handle Message Acknowledgment](https://docs.mulesoft.com/jms-connector/1.2/jms-ack) - [Handle Transactions in JMS](https://docs.mulesoft.com/jms-connector/1.2/jms-transactions) - [JMS Tuning For Performance](https://docs.mulesoft.com/jms-connector/1.2/jms-performance) - [Salesforce Help](https://help.salesforce.com) --- product: JMS Connector version: 1.10 --- # JMS Connector 1.10 > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Connector for JMS (Java Message Service) (JMS Connector) enables sending and receiving messages to queues and topics for any message service that implements the JMS specification. JMS is a widely used API for message-oriented middleware. It enables the communication between different components of a distributed application to be loosely coupled, reliable, and asynchronous. The main features of JMS Connector include: - Publish and subscribe pattern support on any given destination - Listen and reply pattern support on any given destination - Publish and consume pattern support on any given destination, with a fixed or temporary reply queue - Fully compliant with JMS 2.0, 1.1, and 1.0.2 specifications ## Before You Begin To use this connector, you must be familiar with: - Java Message Service - Anypoint Connectors - Mule runtime engine (Mule) - Elements and global elements in a Mule flow - Creating a Mule app using Anypoint Studio or Anypoint Code Builder Before creating an app, you must have access to Anypoint Platform and Anypoint Studio. ## Common Use Cases for the Connector JMS Connector enables you to: - Listen for new messages as they arrive at a specified destination. - Publish a new message and send it to a specified destination. - Consume a message at any given time in the flow from any given specified destination. - Publish a message to any specified destination, and then consume a reply on a different specified destination. For examples, see [JMS Connector Examples](https://docs.mulesoft.com/jms-connector/1.10/jms-examples). ## JMS Messaging Support Models JMS supports two models for messaging: - Point-to-point queues - Publish and subscribe topics ### Point-to-Point Queues In the point-to-point queuing model, a sender posts messages to a particular queue and a receiver reads those messages from that same queue. In this model, the sender knows the destination of the message and posts the message directly to it. The point-to-point queuing model operates as follows: - Only one receiver consumes the received message. - The sender does not need to be running at the time the receiver consumes the message, and the receiver does not need to be running at the time the message is sent. - Every message that is successfully processed is acknowledged by the receiver. ### Publish and Subscribe Topics The publish and subscribe model supports a sender in publishing messages to a particular message topic rather than directly to a particular queue. Receivers subscribe to consume the receive messages on a particular message topic. In this model, neither the sender nor the receiver are aware of each other. An anonymous bulletin board is a good analogy for this concept. The publish and subscribe model operates as follows: - Multiple receivers consume the receive the message, including none if there are no subscribers to the topic. - The sender must create a message topic in such a way that receivers can subscribe to that topic. - The receiver must remain continuously active to consume the receive messages, unless it has established a durable subscription in which case messages sent while the receiver is not connected are redistributed when the receiver reconnects. ## Next Step After you complete the prerequisites, you are ready to create your own app and configure the connector using [Anypoint Studio](https://docs.mulesoft.com/jms-connector/1.10/jms-studio-configuration). ## See Also - [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors) - [Use Exchange to Discover Connectors, Templates, and Examples](https://docs.mulesoft.com/connectors/introduction/intro-use-exchange) - [Salesforce Help](https://help.salesforce.com) --- product: JMS Connector version: 2.0 is-latest-version: true --- # JMS Connector 2.0 > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Connector for JMS (Java Message Service) (JMS Connector) enables sending and receiving messages to queues and topics for any message service that implements the JMS specification. JMS is a widely used API for message-oriented middleware. It enables the communication between different components of a distributed application to be loosely coupled, reliable, and asynchronous. The main features of JMS Connector include: - Publish and subscribe pattern support on any given destination - Listen and reply pattern support on any given destination - Publish and consume pattern support on any given destination, with a fixed or temporary reply queue - Fully compliant with JMS 2.0, 1.1, and 1.0.2 specifications ## Before You Begin To use this connector, you must be familiar with: - Java Message Service - Anypoint Connectors - Mule runtime engine (Mule) - Elements and global elements in a Mule flow - Creating a Mule app using Anypoint Studio or Anypoint Code Builder Before creating an app, you must have access to Anypoint Platform and Anypoint Studio. ## Common Use Cases for the Connector JMS Connector enables you to: - Listen for new messages as they arrive at a specified destination. - Publish a new message and send it to a specified destination. - Consume a message at any given time in the flow from any given specified destination. - Publish a message to any specified destination, and then consume a reply on a different specified destination. For examples, see [JMS Connector Examples](https://docs.mulesoft.com/jms-connector/latest/jms-examples). ## JMS Messaging Support Models JMS supports two models for messaging: - Point-to-point queues - Publish and subscribe topics ### Point-to-Point Queues In the point-to-point queuing model, a sender posts messages to a particular queue and a receiver reads those messages from that same queue. In this model, the sender knows the destination of the message and posts the message directly to it. The point-to-point queuing model operates as follows: - Only one receiver consumes the received message. - The sender does not need to be running at the time the receiver consumes the message, and the receiver does not need to be running at the time the message is sent. - Every message that is successfully processed is acknowledged by the receiver. ### Publish and Subscribe Topics The publish and subscribe model supports a sender in publishing messages to a particular message topic rather than directly to a particular queue. Receivers subscribe to consume the receive messages on a particular message topic. In this model, neither the sender nor the receiver are aware of each other. An anonymous bulletin board is a good analogy for this concept. The publish and subscribe model operates as follows: - Multiple receivers consume the receive the message, including none if there are no subscribers to the topic. - The sender must create a message topic in such a way that receivers can subscribe to that topic. - The receiver must remain continuously active to consume the receive messages, unless it has established a durable subscription in which case messages sent while the receiver is not connected are redistributed when the receiver reconnects. ## Next Step After you complete the prerequisites, you are ready to create your own app and configure the connector using [Anypoint Studio](https://docs.mulesoft.com/jms-connector/latest/jms-studio-configuration). ## See Also - [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors) - [Use Exchange to Discover Connectors, Templates, and Examples](https://docs.mulesoft.com/connectors/introduction/intro-use-exchange) - [Salesforce Help](https://help.salesforce.com) --- product: JMS Connector version: 1.10 --- # JMS Connector Examples > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To fully benefit from using Anypoint Connector for JMS (JMS Connector), see the following examples of configuring the connector operations: - [Configure an ActiveMQ Connection](https://docs.mulesoft.com/jms-connector/1.10/jms-activemq-configuration) Configure JMS Connector to connect to ActiveMQ. - [Manage Message Acknowledgements](https://docs.mulesoft.com/jms-connector/1.10/jms-ack) Configure JMS Connector to manage different acknowledgment configurations, such as automatic acknowledgment on success, immediate acknowledgment, and manual acknowledgment. - [Listen for New Messages](https://docs.mulesoft.com/jms-connector/1.10/jms-listener) Configure the **On New Message** source to listen for new messages as they arrive to the destination. - [Publish New Messages](https://docs.mulesoft.com/jms-connector/1.10/jms-publish) Configure the **Publish** operation to create a new message and send it to the specified destination. - [Consume Messages](https://docs.mulesoft.com/jms-connector/1.10/jms-consume) Configure the **Consume** operation to consume a message at any given time in the flow, from any given destination. - [Publish Messages and Listen for Replies](https://docs.mulesoft.com/jms-connector/1.10/jms-publish-consume) Configure the **Publish consume** operation to publish a message to any destination, and then wait for a reply on a different destination. - [Publish and Consume Messages Within Flows](https://docs.mulesoft.com/jms-connector/1.10/jms-publish-consume-example) Configure the **Publish consume** operation to publish and consume messages within two flows, and use a correlation ID to ensure that the incoming messages are replies to a specific outgoing message. - [Manage Transactions](https://docs.mulesoft.com/jms-connector/1.10/jms-transactions) Configure JMS Connector to execute a series of operations that are performed only when the transaction is committed. - [Configure Topic Subscription](https://docs.mulesoft.com/jms-connector/1.10/jms-topic-subscription) Configure topics subscriptions in JMS Connector to control how subscriptions behave regarding consumers connections and also how these consumers interact with each other. - [Configure XA Transactions](https://docs.mulesoft.com/jms-connector/1.10/jms-xa-transactions) Configure XA transactions using the **XA Connection Pool** and the **Transaction Type** fields. ## See Also - [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors) - [Salesforce Help](https://help.salesforce.com) --- product: JMS Connector version: 2.0 is-latest-version: true --- # JMS Connector Examples > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To fully benefit from using Anypoint Connector for JMS (JMS Connector), see the following examples of configuring the connector operations: - [Configure an ActiveMQ Connection](https://docs.mulesoft.com/jms-connector/latest/jms-activemq-configuration) Configure JMS Connector to connect to ActiveMQ. - [Manage Message Acknowledgements](https://docs.mulesoft.com/jms-connector/latest/jms-ack) Configure JMS Connector to manage different acknowledgment configurations, such as automatic acknowledgment on success, immediate acknowledgment, and manual acknowledgment. - [Listen for New Messages](https://docs.mulesoft.com/jms-connector/latest/jms-listener) Configure the **On New Message** source to listen for new messages as they arrive to the destination. - [Publish New Messages](https://docs.mulesoft.com/jms-connector/latest/jms-publish) Configure the **Publish** operation to create a new message and send it to the specified destination. - [Consume Messages](https://docs.mulesoft.com/jms-connector/latest/jms-consume) Configure the **Consume** operation to consume a message at any given time in the flow, from any given destination. - [Publish Messages and Listen for Replies](https://docs.mulesoft.com/jms-connector/latest/jms-publish-consume) Configure the **Publish consume** operation to publish a message to any destination, and then wait for a reply on a different destination. - [Publish and Consume Messages Within Flows](https://docs.mulesoft.com/jms-connector/latest/jms-publish-consume-example) Configure the **Publish consume** operation to publish and consume messages within two flows, and use a correlation ID to ensure that the incoming messages are replies to a specific outgoing message. - [Manage Transactions](https://docs.mulesoft.com/jms-connector/latest/jms-transactions) Configure JMS Connector to execute a series of operations that are performed only when the transaction is committed. - [Configure Topic Subscription](https://docs.mulesoft.com/jms-connector/latest/jms-topic-subscription) Configure topics subscriptions in JMS Connector to control how subscriptions behave regarding consumers connections and also how these consumers interact with each other. - [Configure XA Transactions](https://docs.mulesoft.com/jms-connector/latest/jms-xa-transactions) Configure XA transactions using the **XA Connection Pool** and the **Transaction Type** fields. ## See Also - [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors) - [Salesforce Help](https://help.salesforce.com) --- product: JMS Connector version: 1.10 --- # JMS Connector Reference 1.10 > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Connector for JMS (JMS Connector) is a JMS 1.0.2b, 1.1, and 2.0 compliant MuleSoft Extension, used to consume and produce JMS messages. The extension supports all JMS functionality including topics and queues, durable subscribers, acknowledgment modes and local transactions. Release Notes: [JMS Connector Release Notes](https://docs.mulesoft.com/release-notes/connector/connector-jms) ## Configurations --- ### Default Configuration Base configuration for JMS Connector #### Parameters
NameTypeDescriptionDefault ValueRequired

Name

String

The name for this configuration. Connectors reference the configuration with this name.

x

Encoding

String

The default encoding of the message body to use if the message doesn’t communicate it

Content Type

String

The default contentType of the message body to use if the message doesn’t communicate it

/

Send Correlation Id

Enumeration, one of:

  • AUTO

  • ALWAYS

  • NEVER

Whether to specify a correlationId when publishing messages. This applies both for custom correlation IDs specifies at the operation level and for default correlation IDs taken from the current event

AUTO

Expiration Policy

Configures the minimum amount of time that a dynamic configuration instance can remain idle before Mule considers it eligible for expiration. This does not mean that the platform expires the instance at the exact moment that it becomes eligible. Mule purges the instances as appropriate.

Ack Mode

Enumeration, one of:

  • IMMEDIATE

  • AUTO

  • MANUAL

  • DUPS_OK

The ConsumerAckMode to use when consuming a message. Can be overridden at the message source level. This attribute has to be IMMEDIATE if transactionType is LOCAL or MULTI

AUTO

Consumer Type

One of:

The ConsumerType to use by default when consuming a message. Can be overridden at the message source level.

Selector

String

Default selector to use for filtering when consuming a message. Can be overridden at the message source level.

Max Redelivery

Number

Do not configure this parameter here, as it has no effect. See [ActiveMQConnectionFactoryConfiguration]

0

Persistent Delivery

Boolean

Sets the default value for the Message#getJMSDeliveryMode. If true, the DeliveryMode#PERSISTENT mode will be used, which instructs the JMS provider to take extra care to insure the message is not lost in transit due to a JMS provider failure.

false

Priority

Number

Defines the default Message#getJMSPriority to use when sending messages

4

Time To Live

Number

Defines the default time the message is in the broker before it expires and is discarded

0

Time To Live Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

A TimeUnit which qualifies the #timeToLive attribute. Defaults to MILLISECONDS

MILLISECONDS

Disable Message Id

Boolean

Defines the default value to use when producing messages, for disabling the Message#getJMSMessageID generation in the broker. Depending on the provider it may or may not have effect

false

Disable Message Timestamp

Boolean

Defines the default value to use, when producing messages, for disable Message#getJMSTimestamp generation in the broker. Depending on the provider it may or may not have effect.

false

Delivery Delay

Number

This is used to determine the message delivery delay time which is calculated by adding the deliveryDelay value specified on the send method to the time the message was sent. Only used in JmsSpecification#JMS_2_0

Delivery Delay Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

A TimeUnit which qualifies the #deliveryDelay attribute. Defaults to MILLISECONDS

MILLISECONDS

Jms Type

String

A message JMSType identifier supplied by a client when a message is sent.

## Operations - [Ack](#ack) - [Consume](#consume) - [Publish](#publish) - [Publish Consume](#publishConsume) - [Recover Session](#recoverSession) ### Associated Sources - [On New Message](#listener) ### Consume `` Operation that allows the user to consume a single message from a given Destination. #### Parameters
NameTypeDescriptionDefault ValueRequired

Configuration

String

The name of the configuration to use.

x

Destination

String

The name of the Destination from where the message should be consumed

x

Consumer Type

One of:

The type of the MessageConsumer that is required for the given destination, along with any extra configurations that are required based on the destination type.

Ack Mode

Enumeration, one of:

  • IMMEDIATE

  • MANUAL

The ConsumerAckMode to configure over the message and Session

Selector

String

A custom JMS selector for filtering the messages

Content Type

String

The Message’s content type

Encoding

String

The Message’s content encoding

Maximum Wait

Number

Maximum time to wait for a message before timing out

10000

Maximum Wait Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

Time unit to use in the maximumWaitTime configurations

MILLISECONDS

Transactional Action

Enumeration, one of:

  • ALWAYS_JOIN

  • JOIN_IF_POSSIBLE

  • NOT_SUPPORTED

The type of joining action that operations can take regarding transactions.

JOIN_IF_POSSIBLE

Target Variable

String

The name of a variable to store the operation’s output.

Target Value

String

An expression to evaluate against the operation’s output and store the expression outcome in the target variable

#[payload]

Reconnection Strategy

A retry strategy in case of connectivity errors.

#### Output

Type

Any

Attributes Type

### For Configurations - [Default Configuration](#config) #### Throws - JMS:RETRY\_EXHAUSTED - JMS:ACK - JMS:DESTINATION\_NOT\_FOUND - JMS:SECURITY - JMS:TIMEOUT - JMS:CONNECTIVITY - JMS:CONSUMING ### Publish `` Operation that allows the user to send a message to a JMS Destination. #### Parameters
NameTypeDescriptionDefault ValueRequired

Configuration

String

The name of the configuration to use.

x

Destination

String

The name of the Destination where the message should be sent

x

Destination Type

Enumeration, one of:

  • QUEUE

  • TOPIC

The DestinationType of the destination

QUEUE

Transactional Action

Enumeration, one of:

  • ALWAYS_JOIN

  • JOIN_IF_POSSIBLE

  • NOT_SUPPORTED

Transactional Action for the operation. Indicates if the publish must be executed or not in a transaction.

JOIN_IF_POSSIBLE

Send Correlation Id

Enumeration, one of:

  • AUTO

  • ALWAYS

  • NEVER

options on whether to include an outbound correlation ID or not

Body

Any

The body of the message

#[payload]

JMS Type

String

The JMSType header of the message

Correlation ID

String

The JMSCorrelationID header of the message

Send Content-Type

Boolean

True if the body type should be sent as a message property

true

Content-Type

String

The content type of the body

Send Encoding

Boolean

True if the body outboundEncoding should be sent as a message property

true

Encoding

String

The outboundEncoding of the message’s body

Reply To

The JMSReplyTo header information of the Destination where this message should be replied to

User Properties

Object

The custom user properties that should be set to this message

JMSX Properties

The JMSX properties that should be set to this message

Persistent Delivery

Boolean

If true, the message is sent using the PERSISTENT JMSDeliveryMode

Priority

Number

The default JMSPriority value to use when sending the message

Time To Live

Number

Defines the default time the message is in the broker before it expires and is discarded

Time To Live Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

Time unit to use in the timeToLive configurations

Disable Message Id

Boolean

If true, the message is flagged to avoid generating its MessageID

Disable Message Timestamp

Boolean

If true, the message is flagged to avoid generating its sent Timestamp

Delivery Delay

Number

Only used by JMS 2.0. Sets the delivery delay to be applied to postpone the message delivery

Delivery Delay Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

Time unit to use in the deliveryDelay configurations

Reconnection Strategy

A retry strategy in case of connectivity errors.

### For Configurations - [Default Configuration](#config) #### Throws - JMS:RETRY\_EXHAUSTED - JMS:ILLEGAL\_BODY - JMS:PUBLISHING - JMS:DESTINATION\_NOT\_FOUND - JMS:SECURITY - JMS:CONNECTIVITY ### Publish Consume `` Operation that allows the user to send a message to a JMS Destination and waits for a response either to the provided ReplyTo destination or to a temporary Destination created dynamically. #### Parameters
NameTypeDescriptionDefault ValueRequired

Configuration

String

The name of the configuration to use.

x

Destination

String

The name of the Destination where the message should be sent

x

Request-Reply Pattern

Enumeration, one of:

  • CORRELATION_ID

  • MESSAGE_ID

  • NONE

CORRELATION_ID

Send Correlation ID

Enumeration, one of:

  • AUTO

  • ALWAYS

  • NEVER

options on whether to include an outbound correlation ID or not

Body

Any

The body of the message

#[payload]

JMS Type

String

The JMSType header of the message

Correlation ID

String

The JMSCorrelationID header of the message

Send Content-Type

Boolean

True if the body type should be sent as a message property

true

Content-Type

String

The content type of the body

Send Encoding

Boolean

True if the body outboundEncoding should be sent as a message property

true

Encoding

String

The outboundEncoding of the message’s body

Reply To

The JMSReplyTo header information of the Destination where this message should be replied to

User Properties

Object

The custom user properties that should be set to this message

JMSX Properties

The JMSX properties that should be set to this message

Persistent Delivery

Boolean

If true, the message is sent using the PERSISTENT JMSDeliveryMode

Priority

Number

The default JMSPriority value to use when sending the message

Time To Live

Number

Defines the default time the message is in the broker before it expires and is discarded

Time To Live Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

Time unit to use in the timeToLive configurations

Disable Message Id

Boolean

If true, the message is flagged to avoid generating its MessageID

Disable Message Timestamp

Boolean

If true, the message is flagged to avoid generating its sent Timestamp

Delivery Delay

Number

Only used by JMS 2.0. Sets the delivery delay to be applied to postpone the message delivery

Delivery Delay Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

Time unit to use in the deliveryDelay configurations

Ack Mode

Enumeration, one of:

  • IMMEDIATE

  • MANUAL

The Session ACK mode to use when consuming the message

Maximum Wait

Number

Maximum time to wait for a message to arrive before timeout

10000

Maximum Wait Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

Time unit to use in the maximumWaitTime configuration

MILLISECONDS

Content Type

String

The content type of the message body to be consumed

Encoding

String

The encoding of the message body to be consumed

Target Variable

String

The name of a variable to store the operation’s output.

Target Value

String

An expression to evaluate against the operation’s output and store the expression outcome in the target variable

#[payload]

Reconnection Strategy

A retry strategy in case of connectivity errors.

#### Output

Type

Any

Attributes Type

### For Configurations - [Default Configuration](#config) #### Throws - JMS:RETRY\_EXHAUSTED - JMS:ILLEGAL\_BODY - JMS:ACK - JMS:PUBLISHING - JMS:DESTINATION\_NOT\_FOUND - JMS:SECURITY - JMS:TIMEOUT - JMS:CONNECTIVITY - JMS:CONSUMING ### Ack `` Allows the user to perform an ACK when the AckMode#MANUAL mode is elected while consuming the Message. As per JMS Spec, performing an ACK over a single message automatically works as an ACK for all the Messages produced in the same JmsSession. #### Parameters
NameTypeDescriptionDefault ValueRequired

Ack Id

String

The AckId of the message to ACK

x

#### Throws - JMS:ACK ### Recover Session `` Allows the user to perform a session recover when the AckMode#MANUAL mode is elected while consuming the Message. As per JMS Spec, performing a session recover automatically redelivers all the consumed messages that had not being acknowledged before this recover. #### Parameters
NameTypeDescriptionDefault ValueRequired

Ack Id

String

The AckId of the message Session to recover

x

#### Throws - JMS:SESSION\_RECOVER ## Sources ### On New Message `` JMS Subscriber for Destinations, allows to listen for incoming Messages #### Parameters
NameTypeDescriptionDefault ValueRequired

Configuration

String

The name of the configuration to use.

x

Destination

String

The name of the Destination from where the message should be consumed

x

Consumer Type

One of:

The Type of the Consumer that should be used for the provided destination

Acknowledge Mode

Enumeration, one of:

  • IMMEDIATE

  • AUTO

  • MANUAL

  • DUPS_OK

The Session ACK mode to use when consuming a message. The acknowledgment mode is determined as follows:

  • If the listener has ackMode="MANUAL", and the Config has ackMode="AUTO", then the listener uses ackMode="MANUAL"

  • If the listener has ackMode=null, and the Config has ackMode="MANUAL", then the listener uses ackMode="MANUAL"

  • If the listener has ackMode=null, and the Config has ackMode=null, then the listener uses ackMode="AUTO" (the consumer config default)

Selector

String

JMS selector to use for filtering incoming messages

Inbound Content-Type

String

The content type of the message body

Inbound Encoding

String

The inboundEncoding of the message body

Number Of Consumers

Number

The number of concurrent consumers to use to receive JMS Messages

4

Transactional Action

Enumeration, one of:

  • ALWAYS_BEGIN

  • NONE

The type of beginning action that sources can take regarding transactions.

NONE

Transaction Type

Enumeration, one of:

  • LOCAL

  • XA

The type of transaction to create. Availability depends on Mule version.

LOCAL

Primary Node Only

Boolean

Whether this source should only be executed on the primary node when running in Cluster

true

Redelivery Policy

Defines a policy for processing the redelivery of the same message

Reconnection Strategy

A retry strategy in case of connectivity errors.

Ignore JMS replyTo header

Boolean

True if no automatic response is needed for messages with destination header

false

Body

Any

The body of the message

#[payload]

JMS Type

String

The JMSType header of the message

Correlation ID

String

The JMSCorrelationID header of the message

Send Content-Type

Boolean

True if the body type should be sent as a message property

true

Content-Type

String

The content type of the body

Send Encoding

Boolean

True if the body outboundEncoding should be sent as a message property

true

Encoding

String

The outboundEncoding of the message’s body

Reply To

The JMSReplyTo header information of the Destination where this message should be replied to

User Properties

Object

The custom user properties that should be set to this message

JMSX Properties

The JMSX properties that should be set to this message

Persistent Delivery

Boolean

Whether or not the delivery should be done with a persistent configuration

Priority

Number

The default JMSPriority value to use when sending the message

Time To Live

Number

Defines the default time the message is in the broker before it expires and is discarded

Time To Live Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

Time unit to use in the timeToLive configurations

Disable Message ID

Boolean

If true, the message is flagged to avoid generating its MessageID

Disable Message Timestamp

Boolean

If true, the message is flagged to avoid generating its sent Timestamp

Delivery Delay

Number

Only used by JMS 2.0. Sets the delivery delay to be applied to postpone the message delivery

Delivery Delay Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

Time unit to use in the deliveryDelay configurations

Send Correlation ID

Enumeration, one of:

  • AUTO

  • ALWAYS

  • NEVER

Options on whether to include an outbound correlation ID or not

Request Reply Pattern

Enumeration, one of:

  • CORRELATION_ID

  • MESSAGE_ID

  • NONE

Indicates which Request Reply Pattern to use. By default uses the Correlation ID of the incoming message to do the Reply-To. In case of configuring the message ID pattern, the ReplyTo will be performed using the message ID of the incoming message. If NONE is selected, not correlation ID will be configured automatically.

CORRELATION_ID

#### Output

Type

Any

Attributes Type

### For Configurations - [Default Configuration](#config) ## Types ### Expiration Policy
FieldTypeDescriptionDefault ValueRequired

Max Idle Time

Number

A scalar time value for the maximum amount of time a dynamic configuration instance should be allowed to be idle before it’s considered eligible for expiration

Time Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

A time unit that qualifies the maxIdleTime attribute

### JMS Attributes
FieldTypeDescriptionDefault ValueRequired

Properties

Container element for all the properties present in a JMS Message.

Headers

Any

All the possible headers of a JMS message.

x

Ack Id

String

The session Ack ID required to acknowledge the current message if one is available, otherwise, it is null.

### JMS Message Properties
FieldTypeDescriptionDefault ValueRequired

All

Any

All the properties of the JMS message as a flattened map.

x

User Properties

Any

The user-provided properties of the JMS message.

x

Jms Properties

Any

JMS message broker and provider properties.

x

Jmsx Properties

JMSX properties of the JMS message.

### JMSX Properties
FieldTypeDescriptionDefault ValueRequired

Jmsx User ID

String

The user identity that sends the message.

Jmsx App ID

String

Identity of the application that sends the message.

Jmsx Delivery Count

Number

The number of message delivery attempts.

Jmsx Group ID

String

The message group identity of the message.

Jmsx Group Seq

Number

The sequence number of the message in the group.

Jmsx Producer TXID

String

Identifier of the transaction that produced the message.

Jmsx Consumer TXID

String

Identifier of the transaction that consumed the message.

Jmsx Rcv Timestamp

Number

The time JMS delivered the message to the consumer.

### Redelivery Policy
FieldTypeDescriptionDefault ValueRequired

Max Redelivery

Number

Do not configure this parameter here, as it has no effect. See [ActiveMQConnectionFactoryConfiguration]

0

Use Secure Hash

Boolean

Whether to use a secure hash algorithm to identify a redelivered message.

Message Digest Algorithm

String

The secure hashing algorithm to use. If not set, the default is SHA-256.

Id Expression

String

Defines one or more expressions to use to determine when a message has been redelivered. This property may only be set if useSecureHash is false.

Object Store

Object Store

The object store where the redelivery counter for each message is stored.

### Reconnect
FieldTypeDescriptionDefault ValueRequired

Frequency

Number

How often to reconnect (in milliseconds)

Count

Number

The number of reconnection attempts to make

blocking

Boolean

If false, the reconnection strategy runs in a separate, non-blocking thread

true

### Reconnect Forever
FieldTypeDescriptionDefault ValueRequired

Frequency

Number

How often in milliseconds to reconnect

blocking

Boolean

If false, the reconnection strategy runs in a separate, non-blocking thread

true

### JMS Destination
FieldTypeDescriptionDefault ValueRequired

Destination

String

The name that identifies the destination where to send a reply to a message.

x

Destination Type

Enumeration, one of:

  • QUEUE

  • TOPIC

the type of this destination

QUEUE

### JMSX Properties
FieldTypeDescriptionDefault ValueRequired

Jmsx User ID

String

The user identity that sends the message.

Jmsx App ID

String

Identity of the application that sends the message.

Jmsx Delivery Count

Number

The number of message delivery attempts.

Jmsx Group ID

String

The message group identity of the message.

Jmsx Group Seq

Number

The sequence number of the message in the group.

Jmsx Producer TXID

String

Identifier of the transaction that produced the message.

Jmsx Consumer TXID

String

Identifier of the transaction that consumed the message.

Jmsx Rcv Timestamp

Number

The time JMS delivered the message to the consumer.

### TLS
FieldTypeDescriptionDefault ValueRequired

Enabled Protocols

String

A comma separated list of protocols enabled for this context.

Enabled Cipher Suites

String

A comma separated list of cipher suites enabled for this context.

Trust Store

Key Store

Revocation Check

### Trust Store
FieldTypeDescriptionDefault ValueRequired

Path

String

The location (which will be resolved relative to the current classpath and file system, if possible) of the trust store.

Password

String

The password used to protect the trust store.

Type

String

The type of store used.

Algorithm

String

The algorithm used by the trust store.

Insecure

Boolean

If true, no certificate validations will be performed, rendering connections vulnerable to attacks. Use at your own risk.

### Key Store
FieldTypeDescriptionDefault ValueRequired

Path

String

The location (which will be resolved relative to the current classpath and file system, if possible) of the key store.

Type

String

The type of store used.

Alias

String

When the key store contains many private keys, this attribute indicates the alias of the key that should be used. If not defined, the first key in the file will be used by default.

Key Password

String

The password used to protect the private key.

Password

String

The password used to protect the key store.

Algorithm

String

The algorithm used by the key store.

### Standard Revocation Check
FieldTypeDescriptionDefault ValueRequired

Only End Entities

Boolean

Only verify the last element of the certificate chain.

Prefer Crls

Boolean

Try CRL instead of OCSP first.

No Fallback

Boolean

Do not use the secondary checking method (the one not selected before).

Soft Fail

Boolean

Avoid verification failure when the revocation server can not be reached or is busy.

### Custom OCSP Responder
FieldTypeDescriptionDefault ValueRequired

Url

String

The URL of the OCSP responder.

Cert Alias

String

Alias of the signing certificate for the OCSP response (must be in the trust store), if present.

### CRL File
FieldTypeDescriptionDefault ValueRequired

Path

String

The path to the CRL file.

### Reconnection
FieldTypeDescriptionDefault ValueRequired

Fails Deployment

Boolean

When the application is deployed, a connectivity test is performed on all connectors. If set to true, deployment fails if the test doesn’t pass after exhausting the associated reconnection strategy.

Reconnection Strategy

The reconnection strategy to use.

### Active MQ Connection Factory Configuration
FieldTypeDescriptionDefault ValueRequired

Broker Url

String

The address of the broker to connect

vm://localhost?broker.persistent=false&broker.useJmx=false

Enable Xa

Boolean

ConnectionFactory should support XA

false

Initial Redelivery Delay

Number

Used to configure the RedeliveryPolicy#getInitialRedeliveryDelay(). This feature is not available in an XA context.

1000

Redelivery Delay

Number

Used to configure the RedeliveryPolicy#getRedeliveryDelay(). This feature is not available in an XA context.

1000

Max Redelivery

Number

Used to configure the RedeliveryPolicy#getMaximumRedeliveries(). Sets the maximum number of times a message will be redelivered before it is sent to the Dead Letter Queue. No redelivery is represented with 0, while -1 means infinite re deliveries accepted.

0

Trusted Packages

Array of String

Allowed packages of classes to send and receive. Starting with versions 5.12.2 and 5.13.0, ActiveMQ requires you to explicitly allow packages that can be exchanged using ObjectMessages.

Trust All Packages

Boolean

Indicates if a class from any package can be sent and received. Enabling this parameter is unsafe because a malicious payload can exploit the host system. Starting with versions 5.12.2 and 5.13.0, ActiveMQ requires you to explicitly allow packages that can be exchanged using ObjectMessages.

false

### Topic Consumer
FieldTypeDescriptionDefault ValueRequired

Durable

Boolean

Indicates if messages are cached when the client is not connected.

false

Shared

Boolean

Indicates if the subscription is shared among consumers.

false

No Local

Boolean

Inhibits the delivery of messages published by its own connection.

false

Subscription Name

String

Name of the subscription.

### Default Caching
FieldTypeDescriptionDefault ValueRequired

Session Cache Size

Number

Size of the session cache.

Cache Producers

Boolean

Indicates whether or not to cache the producer.

true

Cache Consumers

Boolean

Indicates whether or not to cache the consumer.

true

### JNDI Connection Factory
FieldTypeDescriptionDefault ValueRequired

Connection Factory Jndi Name

String

Name of the ConnectionFactory to be discovered using Jndi and used as a delegate of ConnectionFactory

x

Lookup Destination

Enumeration, one of:

  • NEVER

  • ALWAYS

  • TRY_ALWAYS

The Destinations

NEVER

Name Resolver Provider

Provider for the JndiNameResolver

x

### JNDI Name Resolver Provider
FieldTypeDescriptionDefault ValueRequired

Custom JNDI Name Resolver

Reference to a custom JndiNameResolver implementation

Name Resolver Builder

Properties required to build a SimpleJndiNameResolver

### JNDI Name Resolver Properties
FieldTypeDescriptionDefault ValueRequired

Jndi Initial Context Factory

String

The fully qualified name of the factory class that creates the initial context.

x

Jndi Provider Url

String

The JNDI service provider URL.

Provider Properties

Object

Properties to pass to the JNDI Name Resolver Context

### Simple JNDI Name Resolver
FieldTypeDescriptionDefault ValueRequired

Context Factory

Object

The fully qualified name of the factory class that creates the initial context.

Jndi Initial Factory

String

The name of the environment property for specifying the initial context factory to use.

Jndi Provider Properties

Object

Properties to pass to the JNDI Name Resolver Context.

Jndi Provider Url

String

URL of the JNDI provider.

### Cached JNDI Name Resolver
FieldTypeDescriptionDefault ValueRequired

Context Factory

Object

The fully qualified class name of the factory class that creates the initial context.

Jndi Initial Factory

String

The name of the environment property for specifying the initial context factory to use.

Jndi Provider Properties

Object

Properties to pass to the JNDI Name Resolver Context.

Jndi Provider Url

String

URL of the JNDI provider.

### System Properties You can configure the following system properties for the connector:
PropertyDescription

mule.jms.generic.additionalCertificateFileName

JKS file name that contains SSL certificates to add.

mule.jms.generic.additionalCertificatePassword

Truststore password that you set for the mule.jms.generic.additionalCertificatePassword property.

mule.jms.operation.artemis.dispose.delay

Sets a delay during the undeployment stage to prevent thread leaks and allow Artemis time to close the channels it opened with the JMS broker. Set this property when Artemis is the chosen JMS driver.

Note that when you configure these system properties, do not configure the **Caching strategy** field to the **Default caching (Default)** option. Configure the field to **No caching**. ## See Also [Salesforce Help](https://help.salesforce.com) --- product: JMS Connector version: 1.2 --- # JMS Connector Reference 1.2 > For the full documentation index, see: https://docs.mulesoft.com/llms.txt JMS Connector Version 1.2 Anypoint Connector for JMS (JMS Connector) is a JMS 1.0.2b, 1.1, and 2.0 compliant MuleSoft Extension, used to consume and produce JMS messages. The extension supports all JMS functionality including topics and queues, durable subscribers, acknowledgment modes and local transactions. Release Notes: [JMS Connector Release Notes](https://docs.mulesoft.com/release-notes/connector/connector-jms) ## Configurations --- ### Default Configuration Base configuration for JMS Connector #### Parameters
NameTypeDescriptionDefault ValueRequired

Name

String

The name for this configuration. Connectors reference the configuration with this name.

x

Encoding

String

The default encoding of the Message body to use if the message doesn’t communicate it.

Content Type

String

The default contentType of the Message body to use if the message doesn’t communicate it.

/

Send Correlation Id

Enumeration, one of:

  • AUTO

  • ALWAYS

  • NEVER

Whether to specify a correlationId when publishing messages. This applies both for custom correlation IDs specifies at the operation level and for default correlation IDs taken from the current event.

AUTO

Expiration Policy

Configures the minimum amount of time that a dynamic configuration instance can remain idle before the runtime considers it eligible for expiration. This does not mean that the platform expires the instance at the exact moment that it becomes eligible. The runtime purges the instances when it sees fit.

Ack Mode

Enumeration, one of:

  • IMMEDIATE

  • AUTO

  • MANUAL

  • DUPS_OK

The ConsumerAckMode to use when consuming a Message Can be overridden at the message source level. This attribute has to be IMMEDIATE if the transactionType is LOCAL or MULTI.

AUTO

Consumer Type

One of:

The ConsumerType to use by default when consuming a Message Can be overridden at the message source level.

Selector

String

Default selector to use for filtering when consuming a Message Can be overridden at the message source level.

Max Redelivery

Number

NOTE: Do not configure this parameter in the connector, as it has no effect. This must be configured on the broker side.

Used to configure the number of redelivers before discarding the message. No redelivery is represented with 0, while -1 means infinite re deliveries accepted.

0

Persistent Delivery

Boolean

Sets the default value for the Message#getJMSDeliveryMode. If true, the DeliveryMode#PERSISTENT mode will be used, which instructs the JMS provider to take extra care to insure the message is not lost in transit due to a JMS provider failure.

false

Priority

Number

Defines the default Message#getJMSPriority to use when sending messages.

4

Time To Live

Number

Defines the default time the message is in the broker before it expires and is discarded.

0

Time To Live Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

A TimeUnit which qualifies the #timeToLive attribute. Defaults to MILLISECONDS.

MILLISECONDS

Disable Message Id

Boolean

Defines the default value to use when producing messages, for disabling the Message#getJMSMessageID generation in the broker. Depending on the provider it may or may not have effect.

false

Disable Message Timestamp

Boolean

Defines the default value to use, when producing messages, for disable Message#getJMSTimestamp generation in the broker. Depending on the provider it may or may not have effect.

false

Delivery Delay

Number

This is used to determine the Message delivery delay time which is calculated by adding the deliveryDelay value specified on the send method to the time the message was sent. Only used in JmsSpecification#JMS_2_0.

Delivery Delay Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

A TimeUnit which qualifies the #deliveryDelay attribute. Defaults to MILLISECONDS.

MILLISECONDS

Jms Type

String

A message JMSType identifier supplied by a client when a message is sent.

#### Associated Operations - [Consume](#consume) - [Publish](#publish) - [Publish Consume](#publishConsume) #### Associated Sources - [Listener](#listener) ## Operations ### Consume `` Operation that allows the user to consume a single Message from a given Destination. #### Parameters
NameTypeDescriptionDefault ValueRequired

Configuration

String

The name of the configuration to use.

x

Destination

String

The name of the Destination from where the Message should be consumed.

x

Consumer Type

One of:

The type of the MessageConsumer that is required for the given destination, along with any extra configurations that are required based on the destination type.

Ack Mode

Enumeration, one of:

  • IMMEDIATE

  • MANUAL

The ConsumerAckMode to configure over the Message and Session.

Selector

String

A custom JMS selector for filtering the messages.

Content Type

String

The Message’s content type.

Encoding

String

The Message’s content encoding.

Maximum Wait

Number

Maximum time to wait for a message before timing out.

10000

Maximum Wait Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

Time unit to use in the maximumWaitTime configurations.

MILLISECONDS

Transactional Action

Enumeration, one of:

  • ALWAYS_JOIN

  • JOIN_IF_POSSIBLE

  • NOT_SUPPORTED

The type of joining action that operations can take regarding transactions.

JOIN_IF_POSSIBLE

Target Variable

String

The name of a variable to store the operation’s output.

Target Value

String

An expression to evaluate against the operation’s output and store the expression outcome in the target variable.

#[payload]

Reconnection Strategy

A retry strategy in case of connectivity errors.

#### Output

Type

Any

Attributes Type

### For Configurations - [Default Configuration](#config) #### Throws - JMS:RETRY\_EXHAUSTED - JMS:ACK - JMS:DESTINATION\_NOT\_FOUND - JMS:SECURITY - JMS:TIMEOUT - JMS:CONNECTIVITY - JMS:CONSUMING ### Publish `` Operation that allows the user to send a Message to a JMS Destination. #### Parameters
NameTypeDescriptionDefault ValueRequired

Configuration

String

The name of the configuration to use.

x

Destination

String

The name of the Destination where the Message should be sent.

x

Destination Type

Enumeration, one of:

  • QUEUE

  • TOPIC

The DestinationType of the destination

QUEUE

Transactional Action

Enumeration, one of:

  • ALWAYS_JOIN

  • JOIN_IF_POSSIBLE

  • NOT_SUPPORTED

Transactional Action for the operation. Indicates if the publish must be executed or not in a transaction.

JOIN_IF_POSSIBLE

Send Correlation Id

Enumeration, one of:

  • AUTO

  • ALWAYS

  • NEVER

options on whether to include an outbound correlation ID or not.

Body

Any

The body of the Message.

#[payload]

Jms Type

String

The JMSType header of the Message.

Correlation Id

String

The JMSCorrelationID header of the Message.

Send Content Type

Boolean

True if the body type should be sent as a Message property.

true

ContentType

String

The content type of the body.

Send Encoding

Boolean

True if the body outboundEncoding should be sent as a Message property.

true

Encoding

String

The outboundEncoding of the message’s body.

Reply To

The JMSReplyTo header information of the Destination where this Message should be replied to.

User Properties

Object

The custom user properties that should be set to this Message.

JMSX Properties

The JMSX properties that should be set to this Message.

Persistent Delivery

Boolean

If true, the Message is sent using the PERSISTENT JMSDeliveryMode.

Priority

Number

The default JMSPriority value to use when sending the message.

Time To Live

Number

Defines the default time the message is in the broker before it expires and is discarded.

Time To Live Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

Time unit to use in the timeToLive configurations.

Disable Message Id

Boolean

If true, the Message is flagged to avoid generating its MessageID.

Disable Message Timestamp

Boolean

If true, the Message is flagged to avoid generating its sent Timestamp.

Delivery Delay

Number

Only used by JMS 2.0. Sets the delivery delay to be applied to postpone the Message delivery.

Delivery Delay Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

Time unit to use in the deliveryDelay configurations.

Reconnection Strategy

A retry strategy in case of connectivity errors.

### For Configurations - [Default Configuration](#config) #### Throws - JMS:RETRY\_EXHAUSTED - JMS:ILLEGAL\_BODY - JMS:PUBLISHING - JMS:DESTINATION\_NOT\_FOUND - JMS:SECURITY - JMS:CONNECTIVITY ### Publish Consume `` Operation that allows the user to send a message to a JMS Destination and waits for a response either to the provided ReplyTo destination or to a temporary Destination created dynamically. #### Parameters
NameTypeDescriptionDefault ValueRequired

Configuration

String

The name of the configuration to use.

x

Destination

String

The name of the Destination where the Message should be sent.

x

Send Correlation Id

Enumeration, one of:

  • AUTO

  • ALWAYS

  • NEVER

Options on whether to include an outbound correlation ID or not.

Body

Any

The body of the Message.

#[payload]

Jms Type

String

The JMSType header of the Message.

Correlation Id

String

The JMSCorrelationID header of the Message.

Send Content Type

Boolean

True if the body type should be sent as a Message property.

true

ContentType

String

The content type of the body.

Send Encoding

Boolean

True if the body outboundEncoding should be sent as a Message property.

true

Encoding

String

The outboundEncoding of the message’s body.

Reply To

The JMSReplyTo header information of the Destination where this Message should be replied to.

User Properties

Object

The custom user properties that should be set to this Message.

JMSX Properties

The JMSX properties that should be set to this Message.

Persistent Delivery

Boolean

If true, the Message is sent using the PERSISTENT JMSDeliveryMode.

Priority

Number

The default JMSPriority value to use when sending the message.

Time To Live

Number

Defines the default time the message is in the broker before it expires and is discarded.

Time To Live Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

Time unit to use in the timeToLive configurations.

Disable Message Id

Boolean

If true, the Message is flagged to avoid generating its MessageID.

Disable Message Timestamp

Boolean

If true, the Message is flagged to avoid generating its sent Timestamp.

Delivery Delay

Number

Only used by JMS 2.0. Sets the delivery delay to be applied to postpone the Message delivery.

Delivery Delay Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

Time unit to use in the deliveryDelay configurations.

Ack Mode

Enumeration, one of:

  • IMMEDIATE

  • MANUAL

The Session ACK mode to use when consuming the message.

Maximum Wait

Number

Maximum time to wait for a message to arrive before timeout.

10000

Maximum Wait Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

Time unit to use in the maximumWaitTime configuration.

MILLISECONDS

Content Type

String

The content type of the message body to be consumed.

Encoding

String

The encoding of the message body to be consumed.

Target Variable

String

The name of a variable to store the operation’s output.

Target Value

String

An expression to evaluate against the operation’s output and store the expression outcome in the target variable.

#[payload]

Reconnection Strategy

A retry strategy in case of connectivity errors.

#### Output

Type

Any

Attributes Type

### For Configurations - [Default Configuration](#config) #### Throws - JMS:RETRY\_EXHAUSTED - JMS:ILLEGAL\_BODY - JMS:ACK - JMS:PUBLISHING - JMS:DESTINATION\_NOT\_FOUND - JMS:SECURITY - JMS:TIMEOUT - JMS:CONNECTIVITY - JMS:CONSUMING ### Ack `` Allows the user to perform an ACK when the AckMode#MANUAL mode is elected while consuming the Message. As per JMS Spec, performing an ACK over a single Message automatically works as an ACK for all the Messages produced in the same JmsSession. #### Parameters
NameTypeDescriptionDefault ValueRequired

Ack Id

String

The AckId of the Message to ACK.

x

#### Throws - JMS:ACK ### Recover Session `` Allows the user to perform a session recover when the AckMode#MANUAL mode is elected while consuming the Message. As per JMS Spec, performing a session recover automatically redelivers all the consumed messages that had not being acknowledged before this recover. #### Parameters
NameTypeDescriptionDefault ValueRequired

Ack Id

String

The AckId of the Message Session to recover

x

#### Throws - JMS:SESSION\_RECOVER ## Sources ### Listener `` JMS Subscriber for Destinations, allows to listen for incoming Messages. #### Parameters
NameTypeDescriptionDefault ValueRequired

Configuration

String

The name of the configuration to use.

x

Destination

String

The name of the Destination from where the Message should be consumed.

x

Consumer Type

One of:

The Type of the Consumer that should be used for the provided destination.

Ack Mode

Enumeration, one of:

  • IMMEDIATE

  • AUTO

  • MANUAL

  • DUPS_OK

The Session ACK mode to use when consuming a message. The acknowledgment mode is determined as follows:

* If the listener has ackMode="MANUAL", and the Config has ackMode="AUTO", then the listener uses ackMode="MANUAL"
* If the listener has ackMode=null, and the Config has ackMode="MANUAL", then the listener uses ackMode="MANUAL"
* If the listener has ackMode=null, and the Config has ackMode=null, then the listener uses ackMode="AUTO" (the consumer config default)

Selector

String

JMS selector to use for filtering incoming messages.

Inbound Content Type

String

The content type of the message body.

Inbound Encoding

String

The inboundEncoding of the message body.

Number Of Consumers

Number

The number of concurrent consumers to use to receive JMS Messages.

4

Transactional Action

Enumeration, one of:

  • ALWAYS_BEGIN

  • NONE

The type of beginning action that sources can take regarding transactions.

NONE

Transaction Type

Enumeration, one of:

  • LOCAL

  • XA

The type of transaction to create. Availability depends on the runtime version.

LOCAL

Primary Node Only

Boolean

Whether this source should only be executed on the primary node when running in Cluster.

true

Redelivery Policy

Defines a policy for processing the redelivery of the same message.

Reconnection Strategy

A retry strategy in case of connectivity errors.

Body

Any

The body of the Message.

#[payload]

Jms Type

String

The JMSType header of the Message.

Correlation Id

String

The JMSCorrelationID header of the Message.

Send Content Type

Boolean

True if the body type should be sent as a Message property.

true

ContentType

String

The content type of the body.

Send Encoding

Boolean

True if the body outboundEncoding should be sent as a Message property.

true

Encoding

String

The outboundEncoding of the message’s body.

Reply To

The JMSReplyTo header information of the Destination where this Message should be replied to.

User Properties

Object

The custom user properties that should be set to this Message.

JMSX Properties

The JMSX properties that should be set to this Message.

Persistent Delivery

Boolean

Whether or not the delivery should be done with a persistent configuration.

Priority

Number

The default JMSPriority value to use when sending the message.

Time To Live

Number

Defines the default time the message is in the broker before it expires and is discarded.

Time To Live Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

Time unit to use in the timeToLive configurations.

Disable Message Id

Boolean

If true, the Message is flagged to avoid generating its MessageID.

Disable Message Timestamp

Boolean

If true, the Message is flagged to avoid generating its sent Timestamp.

Delivery Delay

Number

Only used by JMS 2.0. Sets the delivery delay to be applied to postpone the Message delivery.

Delivery Delay Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

Time unit to use in the deliveryDelay configurations.

#### Output

Type

Any

Attributes Type

### For Configurations - [Default Configuration](#config) ## Types ### Expiration Policy
FieldTypeDescriptionDefault ValueRequired

Max Idle Time

Number

A scalar time value for the maximum amount of time a dynamic configuration instance should be allowed to be idle before it’s considered eligible for expiration.

Time Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

A time unit that qualifies the maxIdleTime attribute.

### JMS Attributes
FieldTypeDescriptionDefault ValueRequired

Properties

Container element for all the properties present in a JMS Message.

x

Headers

All the possible headers of a JMS Message.

x

Ack Id

String

The session ACK ID required to ACK a the current Message if one is available, or null otherwise.

### JMS Message Properties
FieldTypeDescriptionDefault ValueRequired

All

Object

x

User Properties

Object

x

Jms Properties

Object

x

Jmsx Properties

x

### JMSX Properties
FieldTypeDescriptionDefault ValueRequired

Jmsx User ID

String

The identity of the user sending the message.

Jmsx App ID

String

The identity of the application sending the message.

Jmsx Delivery Count

Number

The number of message delivery attempts.

Jmsx Group ID

String

The identity of the message group this message is part of.

Jmsx Group Seq

Number

The sequence number of this message within the group.

Jmsx Producer TXID

String

The transaction identifier of the transaction within which this message was produced.

Jmsx Consumer TXID

String

The transaction identifier of the transaction within which this message was consumed.

Jmsx Rcv Timestamp

Number

The time JMS delivered the message to the consumer.

### JMS Headers
FieldTypeDescriptionDefault ValueRequired

Destination

Delivery Mode

Number

x

Expiration

Number

x

Priority

Number

x

Message Id

String

Timestamp

Number

x

Correlation Id

String

Reply To

Type

String

Redelivered

Boolean

false

Delivery Time

Number

### JMS Destination
FieldTypeDescriptionDefault ValueRequired

Destination

String

The name that identifies the destination where to send a reply to a message.

x

Destination Type

Enumeration, one of:

  • QUEUE

  • TOPIC

The type of this destination.

QUEUE

### Redelivery Policy
FieldTypeDescriptionDefault ValueRequired

Max Redelivery Count

Number

NOTE: Do not configure this parameter in the connector, as it has no effect. This must be configured on the broker side.

The maximum number of times a message can be redelivered and processed unsuccessfully before triggering process-failed-message.

Use Secure Hash

Boolean

Whether to use a secure hash algorithm to identify a redelivered message.

Message Digest Algorithm

String

The secure hashing algorithm to use. If not set, the default is SHA-256.

Id Expression

String

Defines one or more expressions to use to determine when a message has been redelivered. This property may only be set if useSecureHash is false.

Object Store

Object Store

The object store where the redelivery counter for each message is going to be stored.

### Reconnect
FieldTypeDescriptionDefault ValueRequired

Frequency

Number

How often to reconnect (in milliseconds)

Count

Number

The number of reconnection attempts to make

blocking

Boolean

If false, the reconnection strategy runs in a separate, non-blocking thread

true

### Reconnect Forever
FieldTypeDescriptionDefault ValueRequired

Frequency

Number

How often in milliseconds to reconnect

blocking

Boolean

If false, the reconnection strategy runs in a separate, non-blocking thread

true

### Reconnection
FieldTypeDescriptionDefault ValueRequired

Fails Deployment

Boolean

When the application is deployed, a connectivity test is performed on all connectors. If set to true, deployment fails if the test doesn’t pass after exhausting the associated reconnection strategy.

Reconnection Strategy

The reconnection strategy to use.

### Active MQ Connection Factory Configuration
FieldTypeDescriptionDefault ValueRequired

Broker Url

String

The address of the broker to connect.

vm://localhost?broker.persistent=false&broker.useJmx=false

Enable Xa

Boolean

ConnectionFactory should support XA.

false

Initial Redelivery Delay

Number

Used to configure the RedeliveryPolicy#getInitialRedeliveryDelay().

1000

Redelivery Delay

Number

Used to configure the RedeliveryPolicy#getRedeliveryDelay().

1000

Max Redelivery

Number

NOTE: Do not configure this parameter in the connector, as it has no effect. This must be configured on the broker side.

Used to configure the RedeliveryPolicy#getMaximumRedeliveries(). 0 means no redelivery. -1 means infinite re deliveries are accepted.

0

Trusted Packages

Array of String

Allowed packages of classes to send and receive. Starting with versions 5.12.2 and 5.13.0, ActiveMQ requires you to explicitly allow packages that can be exchanged using ObjectMessages.

Trust All Packages

Boolean

Indicates if a class from any package can be sent and received. Enabling this parameter is unsafe because a malicious payload can exploit the host system. Starting with versions 5.12.2 and 5.13.0, ActiveMQ requires you to explicitly allow packages that can be exchanged using ObjectMessages.

false

### Topic Consumer
FieldTypeDescriptionDefault ValueRequired

Durable

Boolean

Allows an application to receive all the messages published on a topic, including the ones published when there is no consumer associated with it.

Requires a subscriptionName to be provided.

false

Shared

Boolean

Only for JMS 2.0: Allows the processing of messages from at topic subscription by multiple threads, connections or JVMs.

Requires a subscriptionName to be provided.

false

No Local

Boolean

Specifies that messages published to the topic by its own connection must not be added to the subscription.

false

Subscription Name

String

The name to use for the subscription.

### Default Caching
FieldTypeDescriptionDefault ValueRequired

Session Cache Size

Number

Number of sessions to cache.

Cache Producers

Boolean

MessageProducers

true

Cache Consumers

Boolean

MessageConsumers

true

### JNDI Connection Factory
FieldTypeDescriptionDefault ValueRequired

Connection Factory Jndi Name

String

Name of the ConnectionFactory to be discovered using Jndi and used as a delegate of ConnectionFactory.

x

Lookup Destination

Enumeration, one of:

  • NEVER

  • ALWAYS

  • TRY_ALWAYS

The Destinations

NEVER

Name Resolver Provider

Provider for the JndiNameResolver.

x

### JNDI Name Resolver Provider
FieldTypeDescriptionDefault ValueRequired

Custom JNDI Name Resolver

Name Resolver Builder

### JNDI Name Resolver Properties
FieldTypeDescriptionDefault ValueRequired

Jndi Initial Context Factory

String

x

Jndi Provider Url

String

Provider Properties

Object

### Simple JNDI Name Resolver
FieldTypeDescriptionDefault ValueRequired

Context Factory

Any

Jndi Initial Factory

String

Jndi Provider Properties

Object

Jndi Provider Url

String

### Cached JNDI Name Resolver
FieldTypeDescriptionDefault ValueRequired

Context Factory

Any

Jndi Initial Factory

String

Jndi Provider Properties

Object

Jndi Provider Url

String

## See Also [Salesforce Help](https://help.salesforce.com) --- product: JMS Connector version: 2.0 is-latest-version: true --- # JMS Connector Reference 2.0 > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Connector for JMS (JMS Connector) is a JMS 1.0.2b, 1.1, and 2.0 compliant MuleSoft Extension, used to consume and produce JMS messages. The extension supports all JMS functionality including topics and queues, durable subscribers, acknowledgment modes and local transactions. Release Notes: [JMS Connector Release Notes](https://docs.mulesoft.com/release-notes/connector/connector-jms) ## Configurations --- ### Default Configuration Base configuration for JMS Connector #### Parameters
NameTypeDescriptionDefault ValueRequired

Name

String

The name for this configuration. Connectors reference the configuration with this name.

x

Encoding

String

The default encoding of the message body to use if the message doesn’t communicate it

Content Type

String

The default contentType of the message body to use if the message doesn’t communicate it

/

Send Correlation Id

Enumeration, one of:

  • AUTO

  • ALWAYS

  • NEVER

Whether to specify a correlationId when publishing messages. This applies both for custom correlation IDs specifies at the operation level and for default correlation IDs taken from the current event

AUTO

Name

String

The ID used to reference this configuration.

x

Expiration Policy

Configures the minimum amount of time that a dynamic configuration instance can remain idle before Mule considers it eligible for expiration. This does not mean that the platform expires the instance at the exact moment that it becomes eligible. Mule purges the instances as appropriate.

Ack Mode

Enumeration, one of:

  • IMMEDIATE

  • AUTO

  • MANUAL

  • DUPS_OK

The ConsumerAckMode to use when consuming a message. Can be overridden at the message source level. This attribute has to be IMMEDIATE if transactionType is LOCAL or MULTI

AUTO

Consumer Type

One of:

The ConsumerType to use by default when consuming a message. Can be overridden at the message source level.

Selector

String

Default selector to use for filtering when consuming a message. Can be overridden at the message source level.

Max Redelivery

Number

Do not configure this parameter here, as it has no effect. See [ActiveMQConnectionFactoryConfiguration]

0

Persistent Delivery

Boolean

Sets the default value for the Message#getJMSDeliveryMode. If true, the DeliveryMode#PERSISTENT mode will be used, which instructs the JMS provider to take extra care to insure the message is not lost in transit due to a JMS provider failure.

false

Priority

Number

Defines the default Message#getJMSPriority to use when sending messages

4

Time To Live

Number

Defines the default time the message is in the broker before it expires and is discarded

0

Time To Live Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

A TimeUnit which qualifies the #timeToLive attribute. Defaults to MILLISECONDS

MILLISECONDS

Disable Message Id

Boolean

Defines the default value to use when producing messages, for disabling the Message#getJMSMessageID generation in the broker. Depending on the provider it may or may not have effect

false

Disable Message Timestamp

Boolean

Defines the default value to use, when producing messages, for disable Message#getJMSTimestamp generation in the broker. Depending on the provider it may or may not have effect.

false

Delivery Delay

Number

This is used to determine the message delivery delay time which is calculated by adding the deliveryDelay value specified on the send method to the time the message was sent. Only used in JmsSpecification#JMS_2_0

Delivery Delay Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

A TimeUnit which qualifies the #deliveryDelay attribute. Defaults to MILLISECONDS

MILLISECONDS

Jms Type

String

A message JMSType identifier supplied by a client when a message is sent.

## Operations - [Ack](#ack) - [Consume](#consume) - [Publish](#publish) - [Publish Consume](#publishConsume) - [Recover Session](#recoverSession) ### Associated Sources - [On New Message](#listener) ### Consume `` Operation that allows the user to consume a single message from a given Destination. #### Parameters
NameTypeDescriptionDefault ValueRequired

Configuration

String

The name of the configuration to use.

x

Destination

String

The name of the Destination from where the message should be consumed

x

Consumer Type

One of:

The type of the MessageConsumer that is required for the given destination, along with any extra configurations that are required based on the destination type.

Ack Mode

Enumeration, one of:

  • IMMEDIATE

  • MANUAL

The ConsumerAckMode to configure over the message and Session

Selector

String

A custom JMS selector for filtering the messages

Content Type

String

The Message’s content type

Encoding

String

The Message’s content encoding

Maximum Wait

Number

Maximum time to wait for a message before timing out

10000

Maximum Wait Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

Time unit to use in the maximumWaitTime configurations

MILLISECONDS

Transactional Action

Enumeration, one of:

  • ALWAYS_JOIN

  • JOIN_IF_POSSIBLE

  • NOT_SUPPORTED

The type of joining action that operations can take regarding transactions.

JOIN_IF_POSSIBLE

Config Ref

ConfigurationProvider

Name of the configuration to use to execute this component.

Target Variable

String

The name of a variable to store the operation’s output.

Target Value

String

An expression to evaluate against the operation’s output and store the expression outcome in the target variable

#[payload]

Error Mappings

Array of Error Mapping

Set of error mappings.

Reconnection Strategy

A retry strategy in case of connectivity errors.

#### Output

Type

Any

Attributes Type

### For Configurations - [Default Configuration](#config) #### Throws - JMS:RETRY\_EXHAUSTED - JMS:ACK - JMS:DESTINATION\_NOT\_FOUND - JMS:SECURITY - JMS:TIMEOUT - JMS:CONNECTIVITY - JMS:CONSUMING ### Publish `` Operation that allows the user to send a message to a JMS Destination. #### Parameters
NameTypeDescriptionDefault ValueRequired

Configuration

String

The name of the configuration to use.

x

Destination

String

The name of the Destination where the message should be sent

x

Destination Type

Enumeration, one of:

  • QUEUE

  • TOPIC

The DestinationType of the destination

QUEUE

Transactional Action

Enumeration, one of:

  • ALWAYS_JOIN

  • JOIN_IF_POSSIBLE

  • NOT_SUPPORTED

Transactional Action for the operation. Indicates if the publish must be executed or not in a transaction.

JOIN_IF_POSSIBLE

Send Correlation Id

Enumeration, one of:

  • AUTO

  • ALWAYS

  • NEVER

options on whether to include an outbound correlation ID or not

Config Ref

ConfigurationProvider

Name of the configuration to use to execute this component.

Body

Any

The body of the message

#[payload]

JMS Type

String

The JMSType header of the message

Correlation ID

String

The JMSCorrelationID header of the message

Send Content-Type

Boolean

True if the body type should be sent as a message property

true

Content-Type

String

The content type of the body

Send Encoding

Boolean

True if the body outboundEncoding should be sent as a message property

true

Encoding

String

The outboundEncoding of the message’s body

Reply To

The JMSReplyTo header information of the Destination where this message should be replied to

User Properties

Object

The custom user properties that should be set to this message

JMSX Properties

The JMSX properties that should be set to this message

Persistent Delivery

Boolean

If true, the message is sent using the PERSISTENT JMSDeliveryMode

Priority

Number

The default JMSPriority value to use when sending the message

Time To Live

Number

Defines the default time the message is in the broker before it expires and is discarded

Time To Live Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

Time unit to use in the timeToLive configurations

Disable Message Id

Boolean

If true, the message is flagged to avoid generating its MessageID

Disable Message Timestamp

Boolean

If true, the message is flagged to avoid generating its sent Timestamp

Delivery Delay

Number

Only used by JMS 2.0. Sets the delivery delay to be applied to postpone the message delivery

Delivery Delay Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

Time unit to use in the deliveryDelay configurations

Error Mappings

Array of Error Mapping

Set of error mappings.

Reconnection Strategy

A retry strategy in case of connectivity errors.

### For Configurations - [Default Configuration](#config) #### Throws - JMS:RETRY\_EXHAUSTED - JMS:ILLEGAL\_BODY - JMS:PUBLISHING - JMS:DESTINATION\_NOT\_FOUND - JMS:SECURITY - JMS:CONNECTIVITY ### Publish Consume `` Operation that allows the user to send a message to a JMS Destination and waits for a response either to the provided ReplyTo destination or to a temporary Destination created dynamically. #### Parameters
NameTypeDescriptionDefault ValueRequired

Configuration

String

The name of the configuration to use.

x

Destination

String

The name of the Destination where the message should be sent

x

Request-Reply Pattern

Enumeration, one of:

  • CORRELATION_ID

  • MESSAGE_ID

  • NONE

CORRELATION_ID

Send Correlation ID

Enumeration, one of:

  • AUTO

  • ALWAYS

  • NEVER

options on whether to include an outbound correlation ID or not

Config Ref

ConfigurationProvider

Name of the configuration to use to execute this component.

Body

Any

The body of the message

#[payload]

JMS Type

String

The JMSType header of the message

Correlation ID

String

The JMSCorrelationID header of the message

Send Content-Type

Boolean

True if the body type should be sent as a message property

true

Content-Type

String

The content type of the body

Send Encoding

Boolean

True if the body outboundEncoding should be sent as a message property

true

Encoding

String

The outboundEncoding of the message’s body

Reply To

The JMSReplyTo header information of the Destination where this message should be replied to

User Properties

Object

The custom user properties that should be set to this message

JMSX Properties

The JMSX properties that should be set to this message

Persistent Delivery

Boolean

If true, the message is sent using the PERSISTENT JMSDeliveryMode

Priority

Number

The default JMSPriority value to use when sending the message

Time To Live

Number

Defines the default time the message is in the broker before it expires and is discarded

Time To Live Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

Time unit to use in the timeToLive configurations

Disable Message Id

Boolean

If true, the message is flagged to avoid generating its MessageID

Disable Message Timestamp

Boolean

If true, the message is flagged to avoid generating its sent Timestamp

Delivery Delay

Number

Only used by JMS 2.0. Sets the delivery delay to be applied to postpone the message delivery

Delivery Delay Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

Time unit to use in the deliveryDelay configurations

Ack Mode

Enumeration, one of:

  • IMMEDIATE

  • MANUAL

The Session ACK mode to use when consuming the message

Maximum Wait

Number

Maximum time to wait for a message to arrive before timeout

10000

Maximum Wait Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

Time unit to use in the maximumWaitTime configuration

MILLISECONDS

Content Type

String

The content type of the message body to be consumed

Encoding

String

The encoding of the message body to be consumed

Target Variable

String

The name of a variable to store the operation’s output.

Target Value

String

An expression to evaluate against the operation’s output and store the expression outcome in the target variable

#[payload]

Error Mappings

Array of Error Mapping

Set of error mappings.

Reconnection Strategy

A retry strategy in case of connectivity errors.

#### Output

Type

Any

Attributes Type

### For Configurations - [Default Configuration](#config) #### Throws - JMS:RETRY\_EXHAUSTED - JMS:ILLEGAL\_BODY - JMS:ACK - JMS:PUBLISHING - JMS:DESTINATION\_NOT\_FOUND - JMS:SECURITY - JMS:TIMEOUT - JMS:CONNECTIVITY - JMS:CONSUMING ### Ack `` Allows the user to perform an ACK when the AckMode#MANUAL mode is elected while consuming the Message. As per JMS Spec, performing an ACK over a single message automatically works as an ACK for all the Messages produced in the same JmsSession. #### Parameters
NameTypeDescriptionDefault ValueRequired

Ack Id

String

The AckId of the message to ACK

x

Error Mappings

Array of Error Mapping

Set of error mappings.

#### Throws - JMS:ACK ### Recover Session `` Allows the user to perform a session recover when the AckMode#MANUAL mode is elected while consuming the Message. As per JMS Spec, performing a session recover automatically redelivers all the consumed messages that had not being acknowledged before this recover. #### Parameters
NameTypeDescriptionDefault ValueRequired

Ack Id

String

The AckId of the message Session to recover

x

Error Mappings

Array of Error Mapping

Set of error mappings.

#### Throws - JMS:SESSION\_RECOVER ## Sources ### On New Message `` JMS Subscriber for Destinations, allows to listen for incoming Messages #### Parameters
NameTypeDescriptionDefault ValueRequired

Configuration

String

The name of the configuration to use.

x

Destination

String

The name of the Destination from where the message should be consumed

x

Consumer Type

One of:

The Type of the Consumer that should be used for the provided destination

Acknowledge Mode

Enumeration, one of:

  • IMMEDIATE

  • AUTO

  • MANUAL

  • DUPS_OK

The Session ACK mode to use when consuming a message. The acknowledgment mode is determined as follows:

  • If the listener has ackMode="MANUAL", and the Config has ackMode="AUTO", then the listener uses ackMode="MANUAL"

  • If the listener has ackMode=null, and the Config has ackMode="MANUAL", then the listener uses ackMode="MANUAL"

  • If the listener has ackMode=null, and the Config has ackMode=null, then the listener uses ackMode="AUTO" (the consumer config default)

Selector

String

JMS selector to use for filtering incoming messages

Inbound Content-Type

String

The content type of the message body

Inbound Encoding

String

The inboundEncoding of the message body

Number Of Consumers

Number

The number of concurrent consumers to use to receive JMS Messages

4

Transactional Action

Enumeration, one of:

  • ALWAYS_BEGIN

  • NONE

The type of beginning action that sources can take regarding transactions.

NONE

Transaction Type

Enumeration, one of:

  • LOCAL

  • XA

The type of transaction to create. Availability depends on Mule version.

LOCAL

Primary Node Only

Boolean

Whether this source should only be executed on the primary node when running in Cluster

true

Config Ref

ConfigurationProvider

Name of the configuration to use to execute this component.

Redelivery Policy

Defines a policy for processing the redelivery of the same message

Reconnection Strategy

A retry strategy in case of connectivity errors.

Ignore JMS replyTo header

Boolean

True if no automatic response is needed for messages with destination header

false

Body

Any

The body of the message

#[payload]

JMS Type

String

The JMSType header of the message

Correlation ID

String

The JMSCorrelationID header of the message

Send Content-Type

Boolean

True if the body type should be sent as a message property

true

Content-Type

String

The content type of the body

Send Encoding

Boolean

True if the body outboundEncoding should be sent as a message property

true

Encoding

String

The outboundEncoding of the message’s body

Reply To

The JMSReplyTo header information of the Destination where this message should be replied to

User Properties

Object

The custom user properties that should be set to this message

JMSX Properties

The JMSX properties that should be set to this message

Persistent Delivery

Boolean

Whether or not the delivery should be done with a persistent configuration

Priority

Number

The default JMSPriority value to use when sending the message

Time To Live

Number

Defines the default time the message is in the broker before it expires and is discarded

Time To Live Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

Time unit to use in the timeToLive configurations

Disable Message ID

Boolean

If true, the message is flagged to avoid generating its MessageID

Disable Message Timestamp

Boolean

If true, the message is flagged to avoid generating its sent Timestamp

Delivery Delay

Number

Only used by JMS 2.0. Sets the delivery delay to be applied to postpone the message delivery

Delivery Delay Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

Time unit to use in the deliveryDelay configurations

Send Correlation ID

Enumeration, one of:

  • AUTO

  • ALWAYS

  • NEVER

Options on whether to include an outbound correlation ID or not

Request Reply Pattern

Enumeration, one of:

  • CORRELATION_ID

  • MESSAGE_ID

  • NONE

Indicates which Request Reply Pattern to use. By default uses the Correlation ID of the incoming message to do the Reply-To. In case of configuring the message ID pattern, the ReplyTo will be performed using the message ID of the incoming message. If NONE is selected, not correlation ID will be configured automatically.

CORRELATION_ID

#### Output

Type

Any

Attributes Type

### For Configurations - [Default Configuration](#config) ## Types ### Expiration Policy Configures an expiration policy strategy.
FieldTypeDescriptionDefault ValueRequired

Max Idle Time

Number

A scalar time value for the maximum amount of time a dynamic configuration instance should be allowed to be idle before it’s considered eligible for expiration

Time Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

A time unit that qualifies the maxIdleTime attribute

### JMS Attributes
FieldTypeDescriptionDefault ValueRequired

Properties

Container element for all the properties present in a JMS Message.

Headers

Any

All the possible headers of a JMS message.

x

Ack Id

String

The session Ack ID required to acknowledge the current message if one is available, otherwise, it is null.

### JMS Message Properties
FieldTypeDescriptionDefault ValueRequired

All

Any

All the properties of the JMS message as a flattened map.

x

User Properties

Any

The user-provided properties of the JMS message.

x

Jms Properties

Any

JMS message broker and provider properties.

x

Jmsx Properties

JMSX properties of the JMS message.

### JMSX Properties
FieldTypeDescriptionDefault ValueRequired

Jmsx User ID

String

The user identity that sends the message.

Jmsx App ID

String

Identity of the application that sends the message.

Jmsx Delivery Count

Number

The number of message delivery attempts.

Jmsx Group ID

String

The message group identity of the message.

Jmsx Group Seq

Number

The sequence number of the message in the group.

Jmsx Producer TXID

String

Identifier of the transaction that produced the message.

Jmsx Consumer TXID

String

Identifier of the transaction that consumed the message.

Jmsx Rcv Timestamp

Number

The time JMS delivered the message to the consumer.

### Redelivery Policy Configures the redelivery policy for executing requests that generate errors. You can add a redelivery policy to any source in a flow.
FieldTypeDescriptionDefault ValueRequired

Max Redelivery Count

Number

Do not configure this parameter here, as it has no effect. See [ActiveMQConnectionFactoryConfiguration]

0

Message Digest Algorithm

String

The secure hashing algorithm to use. If not set, the default is SHA-256.

Message Identifier

One or more expressions that determine if a message was redelivered. This property can be set only if the Use Secure Hash field is false.

Object Store

Object Store

The object store where the redelivery counter for each message is stored.

### Redelivery Policy Message Identifier Configures how to identify a redelivered message and how to find out when the message was redelivered.
FieldTypeDescriptionDefault ValueRequired

Use Secure Hash

Boolean

Whether to use a secure hash algorithm to identify a redelivered message.

Id Expression

String

Defines one or more expressions to use to determine when a message has been redelivered. This property may only be set if useSecureHash is false.

### Reconnect Configures a standard reconnection strategy, which specifies how often to reconnect and how many reconnection attempts the connector source or operation can make.
FieldTypeDescriptionDefault ValueRequired

Frequency

Number

How often to reconnect (in milliseconds)

Count

Number

The number of reconnection attempts to make

blocking

Boolean

If false, the reconnection strategy runs in a separate, non-blocking thread

true

### Reconnect Forever Configures a forever reconnection strategy by which the connector source or operation attempts to reconnect at a specified frequency for as long as the Mule app runs.
FieldTypeDescriptionDefault ValueRequired

Frequency

Number

How often in milliseconds to reconnect

blocking

Boolean

If false, the reconnection strategy runs in a separate, non-blocking thread

true

### JMS Destination Representation of a Destination that contains its identifier name and the kind of Destination.
FieldTypeDescriptionDefault ValueRequired

Destination

String

The name that identifies the destination where to send a reply to a message.

x

Destination Type

Enumeration, one of:

  • QUEUE

  • TOPIC

the type of this destination

QUEUE

### Error Mapping
FieldTypeDescriptionDefault ValueRequired

Source

Enumeration, one of:

  • ANY

  • REDELIVERY_EXHAUSTED

  • TRANSFORMATION

  • EXPRESSION

  • SECURITY

  • CLIENT_SECURITY

  • SERVER_SECURITY

  • ROUTING

  • CONNECTIVITY

  • RETRY_EXHAUSTED

  • TIMEOUT

Mule error type that triggers this mapping.

Target

String

Name of the error type to map to.

x

### TLS Configures TLS to provide secure communications for the Mule app.
FieldTypeDescriptionDefault ValueRequired

Enabled Protocols

String

A comma separated list of protocols enabled for this context.

Enabled Cipher Suites

String

A comma separated list of cipher suites enabled for this context.

Trust Store

Key Store

Revocation Check

### Trust Store Configures the truststore for TLS.
FieldTypeDescriptionDefault ValueRequired

Path

String

The location (which will be resolved relative to the current classpath and file system, if possible) of the trust store.

Password

String

The password used to protect the trust store.

Type

String

The type of store used.

Algorithm

String

The algorithm used by the trust store.

Insecure

Boolean

If true, no certificate validations will be performed, rendering connections vulnerable to attacks. Use at your own risk.

### Key Store Configures the keystore for the TLS protocol. The keystore you generate contains a private key and a public certificate.
FieldTypeDescriptionDefault ValueRequired

Path

String

The location (which will be resolved relative to the current classpath and file system, if possible) of the key store.

Type

String

The type of store used.

Alias

String

When the key store contains many private keys, this attribute indicates the alias of the key that should be used. If not defined, the first key in the file will be used by default.

Key Password

String

The password used to protect the private key.

Password

String

The password used to protect the key store.

Algorithm

String

The algorithm used by the key store.

### Standard Revocation Check Configures standard revocation checks for TLS certificates.
FieldTypeDescriptionDefault ValueRequired

Only End Entities

Boolean

Only verify the last element of the certificate chain.

Prefer Crls

Boolean

Try CRL instead of OCSP first.

No Fallback

Boolean

Do not use the secondary checking method (the one not selected before).

Soft Fail

Boolean

Avoid verification failure when the revocation server can not be reached or is busy.

### Custom OCSP Responder Configures a custom OCSP responder for certification revocation checks.
FieldTypeDescriptionDefault ValueRequired

Url

String

The URL of the OCSP responder.

Cert Alias

String

Alias of the signing certificate for the OCSP response (must be in the trust store), if present.

### CRL File Specifies the location of the certification revocation list (CRL) file.
FieldTypeDescriptionDefault ValueRequired

Path

String

The path to the CRL file.

### Reconnection Configures a reconnection strategy for an operation.
FieldTypeDescriptionDefault ValueRequired

Fails Deployment

Boolean

When the application is deployed, a connectivity test is performed on all connectors. If set to true, deployment fails if the test doesn’t pass after exhausting the associated reconnection strategy.

Reconnection Strategy

The reconnection strategy to use.

### Active MQ Connection Factory Configuration Contains the parameters required to configure an ActiveMQConnectionFactory.
FieldTypeDescriptionDefault ValueRequired

Broker Url

String

The address of the broker to connect

vm://localhost?broker.persistent=false&broker.useJmx=false

Initial Redelivery Delay

Number

Used to configure the RedeliveryPolicy#getInitialRedeliveryDelay(). This feature is not available in an XA context.

1000

Redelivery Delay

Number

Used to configure the RedeliveryPolicy#getRedeliveryDelay(). This feature is not available in an XA context.

1000

Max Redelivery

Number

Used to configure the RedeliveryPolicy#getMaximumRedeliveries(). Sets the maximum number of times a message will be redelivered before it is sent to the Dead Letter Queue. No redelivery is represented with 0, while -1 means infinite re deliveries accepted.

0

Trusted Packages

Array of String

Allowed packages of classes to send and receive. Starting with versions 5.12.2 and 5.13.0, ActiveMQ requires you to explicitly allow packages that can be exchanged using ObjectMessages.

Trust All Packages

Boolean

Indicates if a class from any package can be sent and received. Enabling this parameter is unsafe because a malicious payload can exploit the host system. Starting with versions 5.12.2 and 5.13.0, ActiveMQ requires you to explicitly allow packages that can be exchanged using ObjectMessages.

false

Verify Host Name

Boolean

If true, the broker’s host name is verified against the host name in the broker’s SSL certificate during the SSL handshake.

false

### Topic Consumer Marks the consumed Destination as a Topic and provides a way to configure topic-specific consumer parameters.
FieldTypeDescriptionDefault ValueRequired

Durable

Boolean

Indicates if messages are cached when the client is not connected.

false

Shared

Boolean

Indicates if the subscription is shared among consumers.

false

No Local

Boolean

Inhibits the delivery of messages published by its own connection.

false

Subscription Name

String

Name of the subscription.

### Default Caching Enables caching and provides default values for all the configurable parameters.
FieldTypeDescriptionDefault ValueRequired

Session Cache Size

Number

Size of the session cache.

Cache Producers

Boolean

Indicates whether or not to cache the producer.

true

Cache Consumers

Boolean

Indicates whether or not to cache the consumer.

true

### JNDI Connection Factory A ConnectionFactory that wraps a ConnectionFactory delegate discovered using a JndiNameResolver.
FieldTypeDescriptionDefault ValueRequired

Connection Factory Jndi Name

String

Name of the ConnectionFactory to be discovered using Jndi and used as a delegate of ConnectionFactory

x

Lookup Destination

Enumeration, one of:

  • NEVER

  • ALWAYS

  • TRY_ALWAYS

The Destinations

NEVER

Name Resolver Provider

Provider for the JndiNameResolver

x

### JNDI Name Resolver Provider
FieldTypeDescriptionDefault ValueRequired

Custom JNDI Name Resolver

Reference to a custom JndiNameResolver implementation

Name Resolver Builder

Properties required to build a SimpleJndiNameResolver

### JNDI Name Resolver Properties
FieldTypeDescriptionDefault ValueRequired

Jndi Initial Context Factory

String

The fully qualified name of the factory class that creates the initial context.

x

Jndi Provider Url

String

The JNDI service provider URL.

Provider Properties

Object

Properties to pass to the JNDI Name Resolver Context

### Simple JNDI Name Resolver Maintains a Context instance that remains open at all times and is always used to perform lookups.
FieldTypeDescriptionDefault ValueRequired

Context Factory

Object

The fully qualified name of the factory class that creates the initial context.

Jndi Initial Factory

String

The name of the environment property for specifying the initial context factory to use.

Jndi Provider Properties

Object

Properties to pass to the JNDI Name Resolver Context.

Jndi Provider Url

String

URL of the JNDI provider.

### Cached JNDI Name Resolver Uses a cache to store already resolved names. The cache has no automated mechanism for cleaning up data; if the cache becomes corrupted, stop and restart the instance to clear it.
FieldTypeDescriptionDefault ValueRequired

Context Factory

Object

The fully qualified class name of the factory class that creates the initial context.

Jndi Initial Factory

String

The name of the environment property for specifying the initial context factory to use.

Jndi Provider Properties

Object

Properties to pass to the JNDI Name Resolver Context.

Jndi Provider Url

String

URL of the JNDI provider.

### System Properties You can configure the following system properties for the connector:
PropertyDescription

mule.jms.generic.additionalCertificateFileName

JKS file name that contains SSL certificates to add.

mule.jms.generic.additionalCertificatePassword

Truststore password that you set for the mule.jms.generic.additionalCertificatePassword property.

mule.jms.operation.artemis.dispose.delay

Sets a delay during the undeployment stage to prevent thread leaks and allow Artemis time to close the channels it opened with the JMS broker. Set this property when Artemis is the chosen JMS driver.

Note that when you configure these system properties, do not configure the **Caching strategy** field to the **Default caching (Default)** option. Configure the field to **No caching**. ## See Also [Salesforce Help](https://help.salesforce.com) --- product: JMS Connector version: 1.10 --- # JMS Connector XML and Maven Support > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Although you can manually code a Mule app in XML, it is more efficient to use Anypoint Studio. If you manually code a Mule runtime engine (Mule) app in XML, either from the Anypoint Studio XML editor or from a text editor, you can get access to the connector in your app by adding reference statements to both your XML Mule flow and the Apache Maven `pom.xml` file. When you add the connector in Studio, Studio automatically populates the XML code with the connector’s namespace and schema location. It also adds a dependency to the `pom.xml` file. ## Add a Namespace for the Connector Paste the following code inside the `` tag of the header of your configuration XML: ```xml http://www.mulesoft.org/schema/mule/jms http://www.mulesoft.org/schema/mule/jms/current/mule-jms.xsd ``` This example shows how the namespace statements are placed in the `` XML block: ```xml ``` ## Add a POM File Dependency The Apache Maven `pom.xml` file generated by Anypoint Studio contains dependencies for a Mule app. If you code a Mule app manually, include this XML snippet in your `pom.xml` file to enable access to this connector: ```xml org.mule.connectors mule-jms-connector x.x.x mule-plugin ``` Replace `x.x.x` with the version that corresponds to the connector you are using. To obtain the most up-to-date `pom.xml` file information: 1. Go to [Anypoint Exchange](https://www.mulesoft.com/exchange/). 2. In Exchange, click **Login** and supply your Anypoint Platform username and password. 3. In Exchange, search for `jms`. 4. Select the connector. 5. Click **Dependency Snippets** near the upper right of the screen. ## See Also - [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors) - [Salesforce Help](https://help.salesforce.com) --- product: JMS Connector version: 2.0 is-latest-version: true --- # JMS Connector XML and Maven Support > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Although you can manually code a Mule app in XML, it is more efficient to use Anypoint Studio. If you manually code a Mule runtime engine (Mule) app in XML, either from the Anypoint Studio XML editor or from a text editor, you can get access to the connector in your app by adding reference statements to both your XML Mule flow and the Apache Maven `pom.xml` file. When you add the connector in Studio, Studio automatically populates the XML code with the connector’s namespace and schema location. It also adds a dependency to the `pom.xml` file. ## Add a Namespace for the Connector Paste the following code inside the `` tag of the header of your configuration XML: ```xml http://www.mulesoft.org/schema/mule/jms http://www.mulesoft.org/schema/mule/jms/current/mule-jms.xsd ``` This example shows how the namespace statements are placed in the `` XML block: ```xml ``` ## Add a POM File Dependency The Apache Maven `pom.xml` file generated by Anypoint Studio contains dependencies for a Mule app. If you code a Mule app manually, include this XML snippet in your `pom.xml` file to enable access to this connector: ```xml org.mule.connectors mule-jms-connector x.x.x mule-plugin ``` Replace `x.x.x` with the version that corresponds to the connector you are using. To obtain the most up-to-date `pom.xml` file information: 1. Go to [Anypoint Exchange](https://www.mulesoft.com/exchange/). 2. In Exchange, click **Login** and supply your Anypoint Platform username and password. 3. In Exchange, search for `jms`. 4. Select the connector. 5. Click **Dependency Snippets** near the upper right of the screen. ## See Also - [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors) - [Salesforce Help](https://help.salesforce.com) --- 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 ``` > [!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 ``` 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 ``` > [!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) --- product: JMS Connector version: 1.10 keywords: jms, connector, consume, message, source, listener --- # Listen for New Messages Using the JMS Connector > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Connector for JMS (JMS Connector) **On New Message** source enables you to listen for and consume new messages as they arrive at the specified destination. If you use JMS Connector with Oracle JMS, the **On New Message** source receives new messages with a delay of 1 to 10 seconds, based on the frequency of the messages. Control this behavior by using `-Doracle.jms.maxSleepTime=xxxx`. ## Listen for New Messages from a Queue In the following example, you configure the **On New Message** source to listen for new messages in the queue specified in the **Destination** field. The operation returns a Mule message each time a JMS message is available in the queue. The Mule message consists of: - The message content as payload - The message metadata in the message attributes By default, the message consumed is acknowledged ("ACKed") only when the execution of the flow receiving the message completes successfully. If instead, an error occurs during the execution of the flow, the session recovers, and the message is redelivered. To configure the source in Studio, follow these steps: 1. In the **Mule Palette** view, select **JMS > On New Message**. 2. Drag **On New Message** to the Studio canvas. 3. In the **On New Message** configuration screen, optionally change the value of the **Display Name** field. 4. In the **On New Message** configuration screen, in **Destination**, specify the name of the destination from which to consume the message, for example, `#[vars.destination]`. ![In the On New Message source screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-onnewmessage-queue.png) Figure 1. JMS Connector On New Message on Queue configuration In the XML editor, the `` configuration looks like this: ```xml ``` ## Listen for New Messages from a Topic Subscription In the following example, you configure the **On New Message** source to listen for new messages from a topic subscription by setting the **Consumer type** field to **Topic consumer**. To configure the source in Studio, follow these steps: 1. In the **Mule Palette** view, select **JMS > On New Message**. 2. Drag **On New Message** to the Studio canvas. 3. In the **On New Message** configuration screen, optionally change the value of the **Display Name** field. 4. In the **On New Message** configuration screen, in **Destination**, specify the name of the destination from which to consume the message for example `#[vars.destination]`. 5. Set the **Consumer type** field to **Topic consumer**: ![In the On New Message source screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-onnewmessage-topic.png) Figure 2. JMS Connector On New Message on Topic subscription configuration In the XML editor, the `` and `` configuration looks like this: ```xml ``` ## Filter Incoming Messages JMS Connector supports filtering messages to consume based on the standard JMS selector language you specify in the **Selector** field of the **On New Message** source. By doing so, you receive only the messages matching the selector language, ignoring any other messages in the destination. In the following example, you configure the **Selector** field to filter messages that matches to a specific header priority queue: 1. In Studio, select the **On New Message** source from your flow. 2. Set the **Destination** field to `openTickets`. 3. Set the **Selector** field to `JMSPriority=8`. ![In the On New Message source screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-onnewmessage-selector.png) Figure 3. JMS Connector On New Message Filtering messages In the XML editor, the `selector` configuration looks like this: ```xml ``` ## Reply to Incoming Messages When an incoming JMS message declares a `ReplyTo` header destination and the message is processed successfully without errors, the **On New Message** source automatically produces a response, and the connector publishes the response to the destination specified in the **Destination** field. In the following example, you configure the response message section of the operation: 1. In Studio, select the **On New Message** source from your flow. 2. In the **Response** section, set the **Ignore Jms replyTo Header** to **True**, which disables the automatic reply. 3. Set the **Body** field to `'Message received was: ' ++ payload`. 4. Set the **User Properties** field to `{'processedAt': now}`. 5. Set the **Persistent delivery** to **True**. 6. Set the **Priority** field to `8`. ![In the On New Message source screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-onnewmessage-response.png) Figure 4. JMS Connector On New Message Response configuration In the XML editor, the `ignoreReplyTo`, `body`, `properties`, `persistentDelivery`, and `priority` configurations looks like this: ```xml #['Message received was: ' ++ payload] #[{'processedAt': now}] ``` ## Configure the Number of Consumers When you need extra processing power, configure the **Number of consumers** field to the number of consumers that the **On New Message** source uses to consume messages concurrently. By default, each source uses `4` consumers that produce messages concurrently. Each consumer waits for the message to be processed, which means that you have a maximum of `4` messages in-flight at the same time. In the following example, you increase the number of consumers in the source: 1. In Studio, select the **On New Message** source from your flow. 2. Increase the **Number of consumers** field from `4` to the number of concurrent consumers that receives the JMS messages, for example, `6`: ![In the On New Message source screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-onnewmessage-consumers.png) Figure 5. JMS Connector On New Message Number of Consumers In the XML editor, the `numberOfConsumers` configuration looks like this: ```xml ``` ## Configure Mime Types and Encoding JMS Connector determines a message’s mime type (`contentType`) based on the `MM_MESSAGE_CONTENT_TYPE` property. However, when you must manage the message’s content, configure the **Inbound Content-Type** field to the particular content type value you need. By default, JMS Connector assumes that Mule runtime engine default encoding matches the encoding in the message if no other information is provided. Use the **Inbound Encoding** field to configure a different type of encoding. In the following example, you configure the inbound content-type and encoding: 1. In Studio, select the **On New Message** source from your flow. 2. Set the **Inbound Content-Type** field to `application/JSON`. 3. Set the **Inbound Encoding** field to `UTF-8`. ![In the On New Message source screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-onnewmessage-types-encoding.png) Figure 6. JMS Connector On New Message Content-Type and Encoding In the XML editor, the `inboundContentType` and `inboundEncoding` configuration looks like this: ```xml ``` ## See Also - [Consume Messages](https://docs.mulesoft.com/jms-connector/1.10/jms-consume) - [Configure Topic Subscriptions](https://docs.mulesoft.com/jms-connector/1.10/jms-topic-subscription) - [Manage Message Acknowledgement](https://docs.mulesoft.com/jms-connector/1.10/jms-ack) --- product: JMS Connector version: 2.0 is-latest-version: true keywords: jms, connector, consume, message, source, listener --- # Listen for New Messages Using the JMS Connector > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Connector for JMS (JMS Connector) **On New Message** source enables you to listen for and consume new messages as they arrive at the specified destination. If you use JMS Connector with Oracle JMS, the **On New Message** source receives new messages with a delay of 1 to 10 seconds, based on the frequency of the messages. Control this behavior by using `-Doracle.jms.maxSleepTime=xxxx`. ## Listen for New Messages from a Queue In the following example, you configure the **On New Message** source to listen for new messages in the queue specified in the **Destination** field. The operation returns a Mule message each time a JMS message is available in the queue. The Mule message consists of: - The message content as payload - The message metadata in the message attributes By default, the message consumed is acknowledged ("ACKed") only when the execution of the flow receiving the message completes successfully. If instead, an error occurs during the execution of the flow, the session recovers, and the message is redelivered. To configure the source in Studio, follow these steps: 1. In the **Mule Palette** view, select **JMS > On New Message**. 2. Drag **On New Message** to the Studio canvas. 3. In the **On New Message** configuration screen, optionally change the value of the **Display Name** field. 4. In the **On New Message** configuration screen, in **Destination**, specify the name of the destination from which to consume the message, for example, `#[vars.destination]`. ![In the On New Message source screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-onnewmessage-queue.png) Figure 1. JMS Connector On New Message on Queue configuration In the XML editor, the `` configuration looks like this: ```xml ``` ## Listen for New Messages from a Topic Subscription In the following example, you configure the **On New Message** source to listen for new messages from a topic subscription by setting the **Consumer type** field to **Topic consumer**. To configure the source in Studio, follow these steps: 1. In the **Mule Palette** view, select **JMS > On New Message**. 2. Drag **On New Message** to the Studio canvas. 3. In the **On New Message** configuration screen, optionally change the value of the **Display Name** field. 4. In the **On New Message** configuration screen, in **Destination**, specify the name of the destination from which to consume the message for example `#[vars.destination]`. 5. Set the **Consumer type** field to **Topic consumer**: ![In the On New Message source screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-onnewmessage-topic.png) Figure 2. JMS Connector On New Message on Topic subscription configuration In the XML editor, the `` and `` configuration looks like this: ```xml ``` ## Filter Incoming Messages JMS Connector supports filtering messages to consume based on the standard JMS selector language you specify in the **Selector** field of the **On New Message** source. By doing so, you receive only the messages matching the selector language, ignoring any other messages in the destination. In the following example, you configure the **Selector** field to filter messages that matches to a specific header priority queue: 1. In Studio, select the **On New Message** source from your flow. 2. Set the **Destination** field to `openTickets`. 3. Set the **Selector** field to `JMSPriority=8`. ![In the On New Message source screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-onnewmessage-selector.png) Figure 3. JMS Connector On New Message Filtering messages In the XML editor, the `selector` configuration looks like this: ```xml ``` ## Reply to Incoming Messages When an incoming JMS message declares a `ReplyTo` header destination and the message is processed successfully without errors, the **On New Message** source automatically produces a response, and the connector publishes the response to the destination specified in the **Destination** field. In the following example, you configure the response message section of the operation: 1. In Studio, select the **On New Message** source from your flow. 2. In the **Response** section, set the **Ignore Jms replyTo Header** to **True**, which disables the automatic reply. 3. Set the **Body** field to `'Message received was: ' ++ payload`. 4. Set the **User Properties** field to `{'processedAt': now}`. 5. Set the **Persistent delivery** to **True**. 6. Set the **Priority** field to `8`. ![In the On New Message source screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-onnewmessage-response.png) Figure 4. JMS Connector On New Message Response configuration In the XML editor, the `ignoreReplyTo`, `body`, `properties`, `persistentDelivery`, and `priority` configurations looks like this: ```xml #['Message received was: ' ++ payload] #[{'processedAt': now}] ``` ## Configure the Number of Consumers When you need extra processing power, configure the **Number of consumers** field to the number of consumers that the **On New Message** source uses to consume messages concurrently. By default, each source uses `4` consumers that produce messages concurrently. Each consumer waits for the message to be processed, which means that you have a maximum of `4` messages in-flight at the same time. In the following example, you increase the number of consumers in the source: 1. In Studio, select the **On New Message** source from your flow. 2. Increase the **Number of consumers** field from `4` to the number of concurrent consumers that receives the JMS messages, for example, `6`: ![In the On New Message source screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-onnewmessage-consumers.png) Figure 5. JMS Connector On New Message Number of Consumers In the XML editor, the `numberOfConsumers` configuration looks like this: ```xml ``` ## Configure Mime Types and Encoding JMS Connector determines a message’s mime type (`contentType`) based on the `MM_MESSAGE_CONTENT_TYPE` property. However, when you must manage the message’s content, configure the **Inbound Content-Type** field to the particular content type value you need. By default, JMS Connector assumes that Mule runtime engine default encoding matches the encoding in the message if no other information is provided. Use the **Inbound Encoding** field to configure a different type of encoding. In the following example, you configure the inbound content-type and encoding: 1. In Studio, select the **On New Message** source from your flow. 2. Set the **Inbound Content-Type** field to `application/JSON`. 3. Set the **Inbound Encoding** field to `UTF-8`. ![In the On New Message source screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-onnewmessage-types-encoding.png) Figure 6. JMS Connector On New Message Content-Type and Encoding In the XML editor, the `inboundContentType` and `inboundEncoding` configuration looks like this: ```xml ``` ## See Also - [Consume Messages](https://docs.mulesoft.com/jms-connector/latest/jms-consume) - [Configure Topic Subscriptions](https://docs.mulesoft.com/jms-connector/latest/jms-topic-subscription) - [Manage Message Acknowledgement](https://docs.mulesoft.com/jms-connector/latest/jms-ack) --- product: JMS Connector version: 1.10 keywords: jms, connector, transactions, transactional --- # Manage Transactions in JMS Connector > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Transactional actions in JMS enable you to execute a series of operations to perform only when the transaction occurs. Use this feature when you want to: - Publish a message as part of a transaction When you use the **Publish** operation, the application sends the message to the destination after the transaction occurs. If for some reason the transaction fails and a rollback occurs, the message is not sent. - Consume a message as part of a transaction When you use either the **On New Message** source or the **Consume** operation, the message is acknowledged only after the transaction occurs. If the transaction rolls back, the message returns to the destination for redelivery. Anypoint Connector for JMS (JMS Connector) provides support for executing the operations by configuring the **Transactional action** field. ## Configure Transactions for Sources If you want the **On New Message** source to use a transactional action when sending the messages, configure the **Transactional action** field to `ALWAYS_BEGIN`. With this configuration, each new message is processed in a transaction that propagates to all the components in the flow and occurs after the flow execution completes successfully. The transaction rolls back if the flow execution returns an error. By default, other components in the flow do not join the transaction created by the **On New Message** source. To execute other operations using the source transaction, configure in those components the **Transactional action** field either with `ALWAYS_JOIN` or `JOIN_IF_POSSIBLE`. In the following example, you configure the transactional action for new messages: 1. In Studio, select the **On New Message** source from your flow. 2. Set the **Destination** field to `${originQueue}`. 3. In the **Advanced** tab, set the **Transactional action** field to `ALWAYS_BEGIN`. ![In the Advanced tab](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-transaction-1.png) Figure 1. JMS Connector Transactional action configuration In the XML editor, the `` and `transactionalAction` configurations look like this: ```xml ``` ## Configure Transactions for Operations To execute an operation like **Publish** or **Consume** as part of a transaction, configure the **Transactional action** field to `ALWAYS_JOIN` or `JOIN_IF_POSSIBLE`. In the following example, you configure the **Publish** and **Consume** operations that join a transaction initiated by the **On New Message** source: 1. In the **Mule Palette** view, select **JMS > On New Message**. 2. Drag **On New Message** onto the Studio canvas. 3. In the **On New Message** configuration screen, set the **Destination** field to `${originQueue}`. 4. In the **Advanced** tab, set the **Transactional action** field to `ALWAYS_BEGIN`. 5. Drag a **Publish** operation to the right of the **On New Message** source. 6. Set the **Destination** field to `#[attributes.properties.userProperties.redirectDestination]`. 7. In the **Advanced** tab, set the **Transactional action** field to `JOIN_IF_POSSIBLE`. 8. Drag a **Consume** operation to the right of the **Publish** operation. 9. Set the **Destination** field to `#[attributes.properties.userProperties.callbackDestination]`. 10. In the **Advanced** tab, set the **Transactional action** field to `JOIN_IF_POSSIBLE`. ![In the Advanced tab](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-transaction-2.png) Figure 2. JMS Connector Transactional action configuration for Consume operation In the XML editor, the `transactionalAction` configuration looks like this: ```xml ``` In the following example, you configure a scoped transaction, using a Try scope component, the JMS **Publish** and **Publish consume** operations, and the Validation module **Is true** operation: 1. In the **Mule Palette** view, select **HTTP > Listener**. 2. Drag **Listener** onto the Studio canvas. 3. In the **Listener** configuration screen, set the **Path** field to `/orders`. 4. Drag a **Try** scope component to the right of the **Listener** source. 5. Set the **Transactional action** field to `ALWAYS_BEGIN`. 6. Drag a JMS **Publish** operation into the **Try** scope component. 7. Set the **Destination** field to `${billingService}` and the **Transactional action** field to `ALWAYS_JOIN`. 8. Drag a JMS **Publish** operation to the right of the first **Publish** operation. 9. Set the **Destination** field to `${shipmentService}` and the **Transactional action** field to `ALWAYS_JOIN`. 10. Drag a **Publish consume** operation to the right of the second **Publish** operation. 11. Set the **Destination** field to `${invoicesVerificationService}`. 12. Drag a Validation module **Is true** operation to the right of the **Publish consume** operation. 13. Select **Expression** for the **Expression** menu and set the value to `#[payload]`. In the XML editor, the `transactionalAction` configuration look like this: ```xml ``` ## See Also - [JMS Connector Examples](https://docs.mulesoft.com/jms-connector/1.10/jms-examples) - [JMS Connector Reference](https://docs.mulesoft.com/jms-connector/1.10/jms-connector-reference) --- product: JMS Connector version: 2.0 is-latest-version: true keywords: jms, connector, transactions, transactional --- # Manage Transactions in JMS Connector > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Transactional actions in JMS enable you to execute a series of operations to perform only when the transaction occurs. Use this feature when you want to: - Publish a message as part of a transaction When you use the **Publish** operation, the application sends the message to the destination after the transaction occurs. If for some reason the transaction fails and a rollback occurs, the message is not sent. - Consume a message as part of a transaction When you use either the **On New Message** source or the **Consume** operation, the message is acknowledged only after the transaction occurs. If the transaction rolls back, the message returns to the destination for redelivery. Anypoint Connector for JMS (JMS Connector) provides support for executing the operations by configuring the **Transactional action** field. ## Configure Transactions for Sources If you want the **On New Message** source to use a transactional action when sending the messages, configure the **Transactional action** field to `ALWAYS_BEGIN`. With this configuration, each new message is processed in a transaction that propagates to all the components in the flow and occurs after the flow execution completes successfully. The transaction rolls back if the flow execution returns an error. By default, other components in the flow do not join the transaction created by the **On New Message** source. To execute other operations using the source transaction, configure in those components the **Transactional action** field either with `ALWAYS_JOIN` or `JOIN_IF_POSSIBLE`. In the following example, you configure the transactional action for new messages: 1. In Studio, select the **On New Message** source from your flow. 2. Set the **Destination** field to `${originQueue}`. 3. In the **Advanced** tab, set the **Transactional action** field to `ALWAYS_BEGIN`. ![In the Advanced tab](/mulesoft/current/en-us/jms-connector/latest/_images/jms-transaction-1.png) Figure 1. JMS Connector Transactional action configuration In the XML editor, the `` and `transactionalAction` configurations look like this: ```xml ``` ## Configure Transactions for Operations To execute an operation like **Publish** or **Consume** as part of a transaction, configure the **Transactional action** field to `ALWAYS_JOIN` or `JOIN_IF_POSSIBLE`. In the following example, you configure the **Publish** and **Consume** operations that join a transaction initiated by the **On New Message** source: 1. In the **Mule Palette** view, select **JMS > On New Message**. 2. Drag **On New Message** onto the Studio canvas. 3. In the **On New Message** configuration screen, set the **Destination** field to `${originQueue}`. 4. In the **Advanced** tab, set the **Transactional action** field to `ALWAYS_BEGIN`. 5. Drag a **Publish** operation to the right of the **On New Message** source. 6. Set the **Destination** field to `#[attributes.properties.userProperties.redirectDestination]`. 7. In the **Advanced** tab, set the **Transactional action** field to `JOIN_IF_POSSIBLE`. 8. Drag a **Consume** operation to the right of the **Publish** operation. 9. Set the **Destination** field to `#[attributes.properties.userProperties.callbackDestination]`. 10. In the **Advanced** tab, set the **Transactional action** field to `JOIN_IF_POSSIBLE`. ![In the Advanced tab](/mulesoft/current/en-us/jms-connector/latest/_images/jms-transaction-2.png) Figure 2. JMS Connector Transactional action configuration for Consume operation In the XML editor, the `transactionalAction` configuration looks like this: ```xml ``` In the following example, you configure a scoped transaction, using a Try scope component, the JMS **Publish** and **Publish consume** operations, and the Validation module **Is true** operation: 1. In the **Mule Palette** view, select **HTTP > Listener**. 2. Drag **Listener** onto the Studio canvas. 3. In the **Listener** configuration screen, set the **Path** field to `/orders`. 4. Drag a **Try** scope component to the right of the **Listener** source. 5. Set the **Transactional action** field to `ALWAYS_BEGIN`. 6. Drag a JMS **Publish** operation into the **Try** scope component. 7. Set the **Destination** field to `${billingService}` and the **Transactional action** field to `ALWAYS_JOIN`. 8. Drag a JMS **Publish** operation to the right of the first **Publish** operation. 9. Set the **Destination** field to `${shipmentService}` and the **Transactional action** field to `ALWAYS_JOIN`. 10. Drag a **Publish consume** operation to the right of the second **Publish** operation. 11. Set the **Destination** field to `${invoicesVerificationService}`. 12. Drag a Validation module **Is true** operation to the right of the **Publish consume** operation. 13. Select **Expression** for the **Expression** menu and set the value to `#[payload]`. In the XML editor, the `transactionalAction` configuration look like this: ```xml ``` ## See Also - [JMS Connector Examples](https://docs.mulesoft.com/jms-connector/latest/jms-examples) - [JMS Connector Reference](https://docs.mulesoft.com/jms-connector/latest/jms-connector-reference) --- product: JMS Connector version: 1.10 --- # Publish and Consume Messages Within Flows Example > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following example illustrates how to configure the Anypoint Connector for JMS (JMS Connector) **Publish consume** operation to publish and consume messages within two flows, and uses a correlation ID to ensure that the incoming messages are replies to a specific outgoing message. ![Both Publish consume flows in the canvas view of Anypoint Studio](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-publishconsume-flow.png) Figure 1. Publish Consume within Flows in Studio - In the first flow, an **HTTP Listener** source initiates the flow by reading random content posted via HTTP. - The **Publish consume** operation publishes a message to a destination queue (`Q1`), containing the content payload received from the HTTP Listener source. - In the second flow, an **On New Message** source listens for the message sent to the queue `Q1` set in the first flow. - Still in the second flow, a **Publish** operation publishes the message in a new destination queue (`Q2`) with a correlation ID attribute that correlates the request and reply messages within the two flows. - Back in the first flow, the **Publish consume** operation consumes the message sent to the queue in `Q2` that matches the correlation ID. - Finally, in the first flow, a **Set Payload** component returns the value `It Works!`. To test this example, you must: 1. Have a Docker instance of ActiveMQ broker. 2. Create two queues, `Q1` and `Q2`, using with the ActiveMQ broker. 3. Create a Mule application that include two flows. 4. Run and test the application using `curl` commands. To install a Docker instance of ActiveMQ broker and how to create the queues, follow their respective documentation guidelines. ## Create the First Flow To start creating your Mule application to publish and consume message, create the first flow: 1. In Studio, in the **Mule Palette** view, select **HTTP > Listener**. 2. Drag the HTTP **Listener** source to the Studio canvas. 3. On the **HTTP Listener** configuration screen, optionally change the value of the **Display Name** field. 4. Set the **Path** field to `/test` 5. Click the plus sign (**+**) next to the **Connector configuration** field to configure a global element that can be used by all instances of HTTP Listener in the app. 6. On the **General** tab, set the following parameters: - **Host**: `All Interfaces [0.0.0.0] (default)` - **Port**: `8081` 7. Click **OK**. 8. Drag the **Publish consume** operation to the right of **HTTP Listener**. 9. Click the plus sign (**+**) next to the **Connector configuration** field to configure a global element that can be used by all instances of **Publish consume** in the app. 10. Set the **Connection** field to **ActiveMQ Connection**. 11. In the **Required Libraries** section, click **Configure…​** to install the dependencies. 12. Set the **Specification** and **Caching strategy** fields to their default values. 13. Set both the **Username** and **Password** fields to `admin`. 14. Set **Factory configuration** to **Edit inline**. 15. Set the **Broker url** field to `tcp://localhost:61616`. 16. Click **OK**. 17. In the **Publish consume > General** section, set the **Destination** field to `Q1` to create the first of the two queues, this one to publish the message that contains the payload of the HTTP Listener. 18. For this example, in the **Message** section, set the **Correlation ID** to `0303456`. 19. Set the **Reply To** field to **Edit inline**. 20. Set the **Destination Name** field to `Q2` to create the second destination queue, this one to consume the message sent by the **Publish** operation in the second flow. 21. In the **Consume Configuration** section, set the **Ack mode** field to **IMMEDIATE**. ![Publish Consume operation configuration in Anypoint Studio](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-publishconsume-operation.png) Figure 2. Publish Consume operation configuration 22. Drag a **Set Payload** component to the right of **Publish consume**. 23. Set the **Value** field to `It Works!`. ## Create the Second Flow Continue creating the application by adding the second flow: 1. Drag a JMS **On New Message** source below the first flow. 2. Repeat Steps 9 through 16 of creating the first flow, to create a global element for the source. 3. In the **On New Message** configuration screen, set the **Destination** field to `Q1` to indicate that the source is listening to the destination set in the **Publish consume** operation of the first flow. 4. Drag the JMS **Publish** operation to the right of the source. 5. Set **Connector configuration** to the same configuration you set for the **On New Message** source. 6. Set the **Destination** field to `Q2`, to indicate that the message is published to the destination queue of the **Publish consume** operation of the first flow. 7. In the **Message** section, set the **Correlation ID** field to `attributes.headers.correlationId` to correlate the request and reply messages. ## Run and Test Your Mule Application After creating your Mule application, run and test it: 1. In Studio, save your Mule app. 2. Click the project name in **Package Explorer** and then click **Run** > **Run As** > **Mule Application**. 3. Open a browser and type `http://0.0.0.0:8081/test`. ## XML for Publishing and Consuming Within Flows Paste this code into your Studio XML editor to quickly load the flow for this example into your Mule app: ```xml ``` ## See Also - [Publish Messages and Consume Replies](https://docs.mulesoft.com/jms-connector/1.10/jms-publish-consume) - [Publish Messages](https://docs.mulesoft.com/jms-connector/1.10/jms-publish) - [JMS Connector Examples](https://docs.mulesoft.com/jms-connector/1.10/jms-examples) --- product: JMS Connector version: 2.0 is-latest-version: true --- # Publish and Consume Messages Within Flows Example > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following example illustrates how to configure the Anypoint Connector for JMS (JMS Connector) **Publish consume** operation to publish and consume messages within two flows, and uses a correlation ID to ensure that the incoming messages are replies to a specific outgoing message. ![Both Publish consume flows in the canvas view of Anypoint Studio](/mulesoft/current/en-us/jms-connector/latest/_images/jms-publishconsume-flow.png) Figure 1. Publish Consume within Flows in Studio - In the first flow, an **HTTP Listener** source initiates the flow by reading random content posted via HTTP. - The **Publish consume** operation publishes a message to a destination queue (`Q1`), containing the content payload received from the HTTP Listener source. - In the second flow, an **On New Message** source listens for the message sent to the queue `Q1` set in the first flow. - Still in the second flow, a **Publish** operation publishes the message in a new destination queue (`Q2`) with a correlation ID attribute that correlates the request and reply messages within the two flows. - Back in the first flow, the **Publish consume** operation consumes the message sent to the queue in `Q2` that matches the correlation ID. - Finally, in the first flow, a **Set Payload** component returns the value `It Works!`. To test this example, you must: 1. Have a Docker instance of ActiveMQ broker. 2. Create two queues, `Q1` and `Q2`, using with the ActiveMQ broker. 3. Create a Mule application that include two flows. 4. Run and test the application using `curl` commands. To install a Docker instance of ActiveMQ broker and how to create the queues, follow their respective documentation guidelines. ## Create the First Flow To start creating your Mule application to publish and consume message, create the first flow: 1. In Studio, in the **Mule Palette** view, select **HTTP > Listener**. 2. Drag the HTTP **Listener** source to the Studio canvas. 3. On the **HTTP Listener** configuration screen, optionally change the value of the **Display Name** field. 4. Set the **Path** field to `/test` 5. Click the plus sign (**+**) next to the **Connector configuration** field to configure a global element that can be used by all instances of HTTP Listener in the app. 6. On the **General** tab, set the following parameters: - **Host**: `All Interfaces [0.0.0.0] (default)` - **Port**: `8081` 7. Click **OK**. 8. Drag the **Publish consume** operation to the right of **HTTP Listener**. 9. Click the plus sign (**+**) next to the **Connector configuration** field to configure a global element that can be used by all instances of **Publish consume** in the app. 10. Set the **Connection** field to **ActiveMQ Connection**. 11. In the **Required Libraries** section, click **Configure…​** to install the dependencies. 12. Set the **Specification** and **Caching strategy** fields to their default values. 13. Set both the **Username** and **Password** fields to `admin`. 14. Set **Factory configuration** to **Edit inline**. 15. Set the **Broker url** field to `tcp://localhost:61616`. 16. Click **OK**. 17. In the **Publish consume > General** section, set the **Destination** field to `Q1` to create the first of the two queues, this one to publish the message that contains the payload of the HTTP Listener. 18. For this example, in the **Message** section, set the **Correlation ID** to `0303456`. 19. Set the **Reply To** field to **Edit inline**. 20. Set the **Destination Name** field to `Q2` to create the second destination queue, this one to consume the message sent by the **Publish** operation in the second flow. 21. In the **Consume Configuration** section, set the **Ack mode** field to **IMMEDIATE**. ![Publish Consume operation configuration in Anypoint Studio](/mulesoft/current/en-us/jms-connector/latest/_images/jms-publishconsume-operation.png) Figure 2. Publish Consume operation configuration 22. Drag a **Set Payload** component to the right of **Publish consume**. 23. Set the **Value** field to `It Works!`. ## Create the Second Flow Continue creating the application by adding the second flow: 1. Drag a JMS **On New Message** source below the first flow. 2. Repeat Steps 9 through 16 of creating the first flow, to create a global element for the source. 3. In the **On New Message** configuration screen, set the **Destination** field to `Q1` to indicate that the source is listening to the destination set in the **Publish consume** operation of the first flow. 4. Drag the JMS **Publish** operation to the right of the source. 5. Set **Connector configuration** to the same configuration you set for the **On New Message** source. 6. Set the **Destination** field to `Q2`, to indicate that the message is published to the destination queue of the **Publish consume** operation of the first flow. 7. In the **Message** section, set the **Correlation ID** field to `attributes.headers.correlationId` to correlate the request and reply messages. ## Run and Test Your Mule Application After creating your Mule application, run and test it: 1. In Studio, save your Mule app. 2. Click the project name in **Package Explorer** and then click **Run** > **Run As** > **Mule Application**. 3. Open a browser and type `http://0.0.0.0:8081/test`. ## XML for Publishing and Consuming Within Flows Paste this code into your Studio XML editor to quickly load the flow for this example into your Mule app: ```xml ``` ## See Also - [Publish Messages and Consume Replies](https://docs.mulesoft.com/jms-connector/latest/jms-publish-consume) - [Publish Messages](https://docs.mulesoft.com/jms-connector/latest/jms-publish) - [JMS Connector Examples](https://docs.mulesoft.com/jms-connector/latest/jms-examples) --- product: JMS Connector version: 1.10 --- # Publish Messages and Consume Replies Using the JMS Connector > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Connector for JMS (JMS Connector) **Publish consume** operation enables you to publish a message to any specified destination, and then consume the message reply on a different specified destination. Request and reply is a very common pattern between applications. When using this operation, the `JMSReplyTo` header of the outgoing message contains the ID of the destination on which your application waits to consume a response. The destination might be a well-known destination or a temporary destination created with the purpose of receiving a single response message. The result of the operation is the message received as a response, with the same structure as invoking the **Consume** operation. ## Receive a Reply on a Temporary Queue To set a temporary queue, you configure the message being sent, and the operation automatically waits for a response. In the following example, you configure the **Publish consume** operation to publish a message with the following characteristics: - Current `payload` as its body - `JMSReplyTo` header configured to a temporary destination - **Destination** field set to `targetDestination` Then, the operation automatically tries to consume the response from the temporary queue until a message is consumed or the **Maximum wait** is reached, in which case it fails with a `JMS:TIMEOUT` error. To configure the operation follow these steps: 1. In your Studio flow, select the **Publish consume** operation. 2. In the connector configuration screen, set the **Destination** field to `targetDestination`. 3. Scroll down to the **Consume Configuration** section and set the **Maximum wait** field to `20`. 4. Set the **Maximum wait unit** to `SECONDS`. ![In the Publish consume configuration screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-publishconsume-config-1.png) Figure 1. Temporary Queue configuration In the XML editor, the `destination` and `` configuration looks like this: ```xml ``` ## Receive a Reply On a Known Queue To set a known queue for replies, configure the **Reply To** field on the outgoing message. In the following example, you configure the **Publish consume** operation to publish a message to the `targetDestination` with the following characteristics: - Current `payload` as its body - `JMSReplyTo` header configured to the known queue - **Reply To** field set to `replyToDestination` Then, the operation automatically tries to consume the response from the known `replyToDestination` queue until a message is consumed or the **Maximum wait** is reached, in which case it fails with a `JMS:TIMEOUT` error. To configure the operation follow these steps: 1. In your Studio flow, select the **Publish consume** operation. 2. In the connector configuration screen, set the **Destination** field to `targetDestination`. 3. In the **Message** section, set the **Reply To** field to **Edit inline**. 4. Set the **Destination Name** field to `replyToDestination`. 5. Scroll down to the **Consume Configuration** section and set the **Maximum wait** field to `20`. 6. Set the **Maximum wait unit** to `SECONDS`. ![In the Publish consume configuration screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-publishconsume-config-2.png) Figure 2. Known Queue configuration In the XML editor, the `destination` and `` configuration looks like this: ```xml ``` ## Configure Request and Reply Patterns JMS uses two well-known request and reply patterns that help you understand how request and reply messages are correlated. In the **Request-Reply Pattern** field of the operation, you can configure the **CORRELATION\_ID (Default)** and **MESSAGE\_ID** patterns. Both ensure that an incoming message is the correct reply to an outgoing message. You can also configure the field to **NONE**, causing the consumer to try to consume from the reply queue without using any selector to correlate messages. This option is useful when working with temporal queues that ensure that the queue has only one message. ### Configure the Correlation ID Pattern The **CORRELATION\_ID (Default)** pattern implies that the operation, after publishing a message to the destination queue, consumes a message using a selector that expects a message with the same correlation ID that was used to publish the request message. The message correlation ID is a value used to link one message with another. In the first flow of the following example, you configure the **Publish consume** operation to publish a message to the `targetDestination` with the following characteristics: - Current `payload` as its body - `JMSReplyTo` header configured to the known queue - **Reply To** field set to `replyToDestination` - **Request-Reply Pattern** field set to **CORRELATION\_ID (Default)** Then, in the second flow, an **On New Message** source reads the published message and responds using the same correlation ID pattern. A **Logger** component, logs the message response. Back in the first flow, the **Publish consume** operation consumes the response received and then another **Logger** component, and logs the final message. To configure the operation follow these steps: 1. In your Studio flow, select the **Publish consume** operation. 2. In the connector configuration screen, set the **Destination** field to `targetDestination`. 3. Set the **Request-Reply Pattern** to **CORRELATION\_ID (Default)**. 4. In the **Message** section, set the **Reply To** field to **Edit inline**. 5. Set the **Destination Name** field to `replyToDestination`. 6. Drag a **Logger** component to right of the Publish consume. 7. Set the **Message** field to `Received message from 'replyToDestination' with Correlation ID: #[attributes.headers.correlationId]`. 8. Drag a JMS **On New Message** source below the first flow. 9. Set the **Destination** field to `targetDestination`. 10. Scroll down to the **Response** section and set the **Request-Reply Pattern** to **CORRELATION\_ID (Default)**. 11. Drag another **Logger** component to right of **On New Message**. 12. Set the **Message** field to `About to reply to 'targetDestination' with Correlation ID: #[attributes.headers.correlationId]`. ![Set the Request-Reply Pattern to CORRELATION\_ID (Default)](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-publishconsume-correlation-example.png) Figure 3. Correlation ID pattern implementation In the XML editor, the `requestReplyPattern` configuration looks like this: ```xml ``` ### Configure the Message ID Pattern The **MESSAGE\_ID** pattern implies that the operation, after publishing a message to the destination queue, consumes a message using a selector that expects a message with a message ID of the same value as the message ID of the request message. The message ID is a value that uniquely identifies each message sent by a provider. In the first flow of the following example, you configure the **Publish consume** operation to publish a message to the `targetDestination` with the following characteristics: - Current `payload` as its body - `JMSReplyTo` header configured to the known queue - **Reply To** field set to `replyToDestination` - **Request-Reply Pattern** field set to **MESSAGE\_ID** Then, in the second flow, an **On New Message** source reads the published message and responds using the same message ID pattern. A **Logger** component, logs the message response. Back in the first flow, the **Publish consume** operation consumes the response received and then another **Logger** component and logs the final message. To configure the operation follow these steps: 1. In your Studio flow, select the **Publish consume** operation. 2. In the connector configuration screen, set the **Destination** field to `targetDestination`. 3. Set the **Request-Reply Pattern** to **MESSAGE\_ID**. 4. In the **Message** section, set the **Reply To** field to **Edit inline**. 5. Set the **Destination Name** field to `replyToDestination`. 6. Drag a **Logger** component to right of **Publish consume**. 7. Set the **Message** field to `Received message from 'replyToDestination' with Message ID: #[attributes.headers.correlationId]`. 8. Drag a JMS **On New Message** source below the first flow. 9. Set the **Destination** field to `targetDestination`. 10. Scroll down to the **Response** section and set the **Request-Reply Pattern** to **MESSAGE\_ID**. 11. Drag another **Logger** component to right of **On New Message**. 12. Set the **Message** field to `About to reply to 'targetDestination' with Message ID: #[attributes.headers.messageId]`. ![Set the Request-Reply Pattern to MESSAGE\_ID](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-publishconsume-message-example.png) Figure 4. Message ID pattern implementation ```xml ``` ## See Also - [Publish Messages](https://docs.mulesoft.com/jms-connector/1.10/jms-publish) - [JMS Connector Examples](https://docs.mulesoft.com/jms-connector/1.10/jms-examples) --- product: JMS Connector version: 2.0 is-latest-version: true --- # Publish Messages and Consume Replies Using the JMS Connector > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Connector for JMS (JMS Connector) **Publish consume** operation enables you to publish a message to any specified destination, and then consume the message reply on a different specified destination. Request and reply is a very common pattern between applications. When using this operation, the `JMSReplyTo` header of the outgoing message contains the ID of the destination on which your application waits to consume a response. The destination might be a well-known destination or a temporary destination created with the purpose of receiving a single response message. The result of the operation is the message received as a response, with the same structure as invoking the **Consume** operation. ## Receive a Reply on a Temporary Queue To set a temporary queue, you configure the message being sent, and the operation automatically waits for a response. In the following example, you configure the **Publish consume** operation to publish a message with the following characteristics: - Current `payload` as its body - `JMSReplyTo` header configured to a temporary destination - **Destination** field set to `targetDestination` Then, the operation automatically tries to consume the response from the temporary queue until a message is consumed or the **Maximum wait** is reached, in which case it fails with a `JMS:TIMEOUT` error. To configure the operation follow these steps: 1. In your Studio flow, select the **Publish consume** operation. 2. In the connector configuration screen, set the **Destination** field to `targetDestination`. 3. Scroll down to the **Consume Configuration** section and set the **Maximum wait** field to `20`. 4. Set the **Maximum wait unit** to `SECONDS`. ![In the Publish consume configuration screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-publishconsume-config-1.png) Figure 1. Temporary Queue configuration In the XML editor, the `destination` and `` configuration looks like this: ```xml ``` ## Receive a Reply On a Known Queue To set a known queue for replies, configure the **Reply To** field on the outgoing message. In the following example, you configure the **Publish consume** operation to publish a message to the `targetDestination` with the following characteristics: - Current `payload` as its body - `JMSReplyTo` header configured to the known queue - **Reply To** field set to `replyToDestination` Then, the operation automatically tries to consume the response from the known `replyToDestination` queue until a message is consumed or the **Maximum wait** is reached, in which case it fails with a `JMS:TIMEOUT` error. To configure the operation follow these steps: 1. In your Studio flow, select the **Publish consume** operation. 2. In the connector configuration screen, set the **Destination** field to `targetDestination`. 3. In the **Message** section, set the **Reply To** field to **Edit inline**. 4. Set the **Destination Name** field to `replyToDestination`. 5. Scroll down to the **Consume Configuration** section and set the **Maximum wait** field to `20`. 6. Set the **Maximum wait unit** to `SECONDS`. ![In the Publish consume configuration screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-publishconsume-config-2.png) Figure 2. Known Queue configuration In the XML editor, the `destination` and `` configuration looks like this: ```xml ``` ## Configure Request and Reply Patterns JMS uses two well-known request and reply patterns that help you understand how request and reply messages are correlated. In the **Request-Reply Pattern** field of the operation, you can configure the **CORRELATION\_ID (Default)** and **MESSAGE\_ID** patterns. Both ensure that an incoming message is the correct reply to an outgoing message. You can also configure the field to **NONE**, causing the consumer to try to consume from the reply queue without using any selector to correlate messages. This option is useful when working with temporal queues that ensure that the queue has only one message. ### Configure the Correlation ID Pattern The **CORRELATION\_ID (Default)** pattern implies that the operation, after publishing a message to the destination queue, consumes a message using a selector that expects a message with the same correlation ID that was used to publish the request message. The message correlation ID is a value used to link one message with another. In the first flow of the following example, you configure the **Publish consume** operation to publish a message to the `targetDestination` with the following characteristics: - Current `payload` as its body - `JMSReplyTo` header configured to the known queue - **Reply To** field set to `replyToDestination` - **Request-Reply Pattern** field set to **CORRELATION\_ID (Default)** Then, in the second flow, an **On New Message** source reads the published message and responds using the same correlation ID pattern. A **Logger** component, logs the message response. Back in the first flow, the **Publish consume** operation consumes the response received and then another **Logger** component, and logs the final message. To configure the operation follow these steps: 1. In your Studio flow, select the **Publish consume** operation. 2. In the connector configuration screen, set the **Destination** field to `targetDestination`. 3. Set the **Request-Reply Pattern** to **CORRELATION\_ID (Default)**. 4. In the **Message** section, set the **Reply To** field to **Edit inline**. 5. Set the **Destination Name** field to `replyToDestination`. 6. Drag a **Logger** component to right of the Publish consume. 7. Set the **Message** field to `Received message from 'replyToDestination' with Correlation ID: #[attributes.headers.correlationId]`. 8. Drag a JMS **On New Message** source below the first flow. 9. Set the **Destination** field to `targetDestination`. 10. Scroll down to the **Response** section and set the **Request-Reply Pattern** to **CORRELATION\_ID (Default)**. 11. Drag another **Logger** component to right of **On New Message**. 12. Set the **Message** field to `About to reply to 'targetDestination' with Correlation ID: #[attributes.headers.correlationId]`. ![Set the Request-Reply Pattern to CORRELATION\_ID (Default)](/mulesoft/current/en-us/jms-connector/latest/_images/jms-publishconsume-correlation-example.png) Figure 3. Correlation ID pattern implementation In the XML editor, the `requestReplyPattern` configuration looks like this: ```xml ``` ### Configure the Message ID Pattern The **MESSAGE\_ID** pattern implies that the operation, after publishing a message to the destination queue, consumes a message using a selector that expects a message with a message ID of the same value as the message ID of the request message. The message ID is a value that uniquely identifies each message sent by a provider. In the first flow of the following example, you configure the **Publish consume** operation to publish a message to the `targetDestination` with the following characteristics: - Current `payload` as its body - `JMSReplyTo` header configured to the known queue - **Reply To** field set to `replyToDestination` - **Request-Reply Pattern** field set to **MESSAGE\_ID** Then, in the second flow, an **On New Message** source reads the published message and responds using the same message ID pattern. A **Logger** component, logs the message response. Back in the first flow, the **Publish consume** operation consumes the response received and then another **Logger** component and logs the final message. To configure the operation follow these steps: 1. In your Studio flow, select the **Publish consume** operation. 2. In the connector configuration screen, set the **Destination** field to `targetDestination`. 3. Set the **Request-Reply Pattern** to **MESSAGE\_ID**. 4. In the **Message** section, set the **Reply To** field to **Edit inline**. 5. Set the **Destination Name** field to `replyToDestination`. 6. Drag a **Logger** component to right of **Publish consume**. 7. Set the **Message** field to `Received message from 'replyToDestination' with Message ID: #[attributes.headers.correlationId]`. 8. Drag a JMS **On New Message** source below the first flow. 9. Set the **Destination** field to `targetDestination`. 10. Scroll down to the **Response** section and set the **Request-Reply Pattern** to **MESSAGE\_ID**. 11. Drag another **Logger** component to right of **On New Message**. 12. Set the **Message** field to `About to reply to 'targetDestination' with Message ID: #[attributes.headers.messageId]`. ![Set the Request-Reply Pattern to MESSAGE\_ID](/mulesoft/current/en-us/jms-connector/latest/_images/jms-publishconsume-message-example.png) Figure 4. Message ID pattern implementation ```xml ``` ## See Also - [Publish Messages](https://docs.mulesoft.com/jms-connector/latest/jms-publish) - [JMS Connector Examples](https://docs.mulesoft.com/jms-connector/latest/jms-examples) --- product: JMS Connector version: 1.2 --- # Publish Messages and Listen for Replies > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Request and reply is a very common pattern between applications, thus the JMS connector provides the `publish-consume` operation specifically for that. The `publish-consume` operation lets you publish a message to any destination, and then wait for a reply on a different destination. When using this operation, the JMSReplyTo header of the outgoing message contains the ID of the destination on which your application waits for a response. This destination may be a well-known destination, or it may be a temporary destination created on the fly with the purpose of receiving a single response message. Finally, the result of the operation is the message received as a response, with the same structure as if a `consume` operation was invoked. ## Wait For a Reply On a Temporary Queue Using a temporary queue to wait for a response is very simple, just configure the message being sent and the operation automatically waits for a response in a temporary queue: ```xml ``` In this example, the operation publishes a message with the current `payload` as its body and the `JMSReplyTo header` configured to a temporary destination, to the `targetDestination`. Then, it automatically tries to consume the response from that temporary queue until a message is consumed or the `maximumWait` is reached, in which case it fails with a `JMS:TIMEOUT` error). ## Receive the Reply On a Known Queue In many cases you don’t want to reply to queues to be created on a per-request basis, but instead a well-known queue is used for replies. For this cases, all you have to do is to configure the `reply-to` parameter on the outgoing message: ```xml ``` Now the operation publishes a message to the `targetDestination` with the current `payload` as its body and the `JMSReplyTo` header configured with the `replyToDestination`. Then, it automatically tries to consume the response from the `replyToDestination` queue until a message is consumed or the `maximumWait` is reached, in which case it fails with a `JMS:TIMEOUT` error. ## Request Reply Patterns As of JMS Connector 1.6.0: In JMS, there exists two well know Request-Reply patterns for how request and reply messages are correlated. This ensures that an incoming message is the proper reply of an outgoing message. ### Correlation ID Pattern This pattern is the default one in the **Publish Consume** operation, the usage of this pattern implies that the operation after publishing a message to the destination queue, consumes a message using a selector that expects a message with the same Correlation ID to be used to publish the request message. Client and Listener JMS Correlation ID pattern implementation ```xml ``` ### Message ID Pattern Different from the Correlation ID Pattern is the Message ID pattern that implies that an operation after publishing a message to the destination queue, will consume a message using a selector that expects a message with a Correlation ID of the same value as the Message ID of the request message. Client and Listener JMS Message ID pattern implementation ```xml ``` ### None Also the operation can be configured to not use any of above patterns, and the consumer will try to consume from the reply queue without using any selector to correlate messages. This option is useful when working with temporal queues that ensure that the queue will have only one message. ## See Also - [To Publish Messages](https://docs.mulesoft.com/jms-connector/1.2/jms-publish) --- product: JMS Connector version: 1.10 keywords: jms, connector, publish --- # Publish Messages Using JMS Connector > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The Anypoint Connector for JMS (JMS Connector) **Publish** operation enables you to create a new JMS message and send it to the specified destination, whether it is a queue or a topic. Using the operation, you can configure not only the content of the message, but also any necessary headers. ## Publish a Message to a Queue The **Publish** operation publishes whatever is in the message payload to the specified queue. In the following example, you configure the operation to publish a message to a queue specified in the **Destination** field: 1. In your Studio flow, select the **Publish** operation. 2. Set the **Destination** field to the queue name, for example, `invoiceQueue`. ![In the Publish configuration screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-publish-config-1.png) Figure 1. Publish operation configuration to a queue In the XML editor, the `` and `destination` configurations look like this: ```xml ``` If you must transform the payload because it is not in the correct format, you could place a DataWeave transformation before the **Publish** operation, but that would cause the message payload to change and impact the operation placed after the transformation. To avoid this impact, place the DataWeave transformation inside the **Publish** operation. The transformation generates the content to publish without affecting the message in transit. In the following example, you configure the transformation inside the operation: 1. In your Studio flow, select the **Publish** operation. 2. Set the **Destination** field to the queue name, for example, `invoiceQueue`. 3. In the **Body** field, set the following DataWeave transformation: ```DataWeave %dw 2.0 output application/json --- payload.payments ``` ![In the Publish configuration screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-publish-config-2.png) Figure 2. Publish operation configuration with DataWeave Transformation In the XML editor, the `` configuration looks like this: ```xml #[%dw 2.0 output application/json --- payload.payments ] ``` ## Publish a Message to a Topic The **Publish** operation can also publish a message to a specified topic destination. Because all the configurations of the operation and the message are identical, you just need only to configure the **Destination type** field to **TOPIC**. In the following example, you configure the operation to publish a message to a topic destination: 1. In your Studio flow, select the **Publish** operation. 2. Set the **Destination** field to the queue name, for example, .Publish operation configuration to a topic destination image::jms-publish-config-3.png\[In the Publish configuration screen, set the Destination type field to TOPIC\] In the XML editor, the `` and `destinationType` configurations look like this: ```xml #[%dw 2.0 output application/json --- payload.payments ] ``` ## Customize Message Delivery Each JMS message has a set of headers that enables you to communicate metadata such as the time to live or message priority. ### Configure a Priority Queue To configure a priority queue, set the **Priority** field to a value different from the default: 1. In your Studio flow, select the **Publish** operation. 2. Set the **Destination** field to the queue name, for example, `priorityQueue`. 3. In the **Publish Configuration** section, set the **Priority** field to `attributes.queryParams.priority`. ![In the Publish configuration screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-publish-config-4.png) Figure 3. Publish operation Priority configuration In the XML editor, the `` and `priority` configurations look like this: ```xml ``` ### Configure a Time To Live Every JMS message published is sent with a time-to-live header that declares how long the message is available for consumption it before it expires. In the operation, configure the **Time to live** and **Time to live unit** fields: 1. In your Studio flow, select the **Publish** operation. 2. Set the **Destination** field to the queue name, for example `vars.destination`. 3. In the **Publish Configuration** section, set the **Time to live** field to `vars.timeToLive`. 4. Set the **Time to live unit** field to **SECONDS**. ![In the Publish configuration screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-publish-config-5.png) Figure 4. Publish operation Time to live configuration In the XML editor, the `timeToLive` and `timeToLiveUnit` configurations looks like this: ```xml ``` If you are using the JMS 2.0 specification, you can also control the message delivery delay, which is how long to wait before making the message available to consumers. In the operation, configure the **Delivery delay** and **Delivery delay unit** fields: 1. In your Studio flow, select the **Publish** operation. 2. Set the **Destination** field to the queue name, for example, `vars.destination`. 3. Set the **Delivery delay** field to `${msgInitialDelay}`. 4. Set the **Delivery delay unit** field to **MILLISECONDS**. ![In the Publish configuration screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-publish-config-6.png) Figure 5. Publish operation Delivery Delay configuration In the XML editor, the `deliveryDelay` and `deliveryDelayUnit` configurations look like this: ```xml ``` ## Configure a Reply Destination When you require an asynchronous reply to the sent message, the **Publish** operation enables you to declare any reply-to destination in the **Reply to** field. The reply destination is communicated as a JMS header to the consumer of the message. In the following example, you configure the reply-to destination: 1. In your Studio flow, select the **Publish** operation. 2. Set the **Destination** field to the queue name, for example, `vars.destination`. 3. Set the **Reply to** field to **Edit inline**. 4. Set the **Destination name** field to `${completionEventsDestination}`. 5. Set the **Destination type** field to **TOPIC**. ![In the Publish configuration screen, set the Reply To to Edit inline, set a name for the Destination name field, and set the Destination type field to TOPIC.](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-publish-config-7.png) Figure 6. Publish operation Reply To configuration In the XML editor, the ``, `destination` and `destinationType` configurations look like this: ```xml ``` ## Configure the Correlation ID The **Publish** operation enables you to configure a correlation ID for the outgoing message in the **Correlation ID** field. First you must configure whether you want to send the correlation ID when publishing the message. If so, configure the **Send correlation id** field to any of the following options: - **ALWAYS** Always sends the header - **NEVER** Never sends the header - **AUTO** The default value, which uses the application configuration Then you can either use the correlation ID of the event that is sending the message, or you can configure your own custom correlation ID in the message builder: 1. In your Studio flow, select the **Publish** operation. 2. Set the **Destination** field to the queue name, for example, `attributes.headers.replyTo.destination`. 3. Set the **Send correlation id** field to **ALWAYS**. 4. Set the **Correlation ID** field to `attributes.headers.correlationId`. ![In the Publish configuration screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-publish-config-8.png) Figure 7. Publish operation Correlation ID configuration In the XML editor, the `endCorrelationId` and `correlationId` configurations look like this: ```xml ``` ## Configure Message Properties Use properties in your JMS message to do things like establishing compatibility with other messaging systems or creating custom message selectors Some of these properties are well-known JMS standards, but others depend on the implementation or custom user configurations. The **Publish** operation enables you to configure all these properties directly in the message. ### Configure User Properties Whenever you must set a property for an outgoing message, configure the **Properties** field in the message and perform an inline declaration of a map using DataWeave: 1. In your Studio flow, select the **Publish** operation. 2. Set the **Destination** field to the queue name, for example, `${bridgeDestination}`. 3. Set the **Destination type** field to **TOPIC**. 4. Set the **Body** field to `"bridged_" ++ payload`. 5. Set the **Properties** field to the following DataWeave code: ```DataWeave { AUTH_TYPE: 'jwt', AUTH_TOKEN: attributes.queryParams.token } ``` ![In the Publish configuration screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-publish-config-9.png) Figure 8. Publish operation Properties configuration In the XML editor, the `` and `` configurations look like this: ```xml #["bridged_" ++ payload] #[{ AUTH_TYPE: 'jwt', AUTH_TOKEN: attributes.queryParams.token }] ``` ### Configure JMSX Properties The JMS spec includes JMSX properties, a set well-known properties that contain metadata about the message. In the following example, you configure these properties in the **JMSX Properties** field of the message: 1. In your Studio flow, select the **Publish** operation. 2. Set the **Destination** field to the queue name, for example, `${bridgeDestination}`. 3. Set the **Destination type** field to **TOPIC**. 4. Set the **Body** field to `"bridged_" ++ payload`. 5. Set the **JMSX Properties** field to **Edit inline**. 6. Set the **Jmsx group id** field to `vars.currentGroup`. 7. Set the **Jmsx user id** field to `${username}`. ![In the Publish configuration screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-publish-config-10.png) Figure 9. Publish operation JMSX Properties configuration In the XML editor, the ``, `jmsxGroupID` and `jmsxUserID` configurations look like this: ```xml #["bridged_" ++ payload] ``` ## See Also [Publish Messages and Consume Replies](https://docs.mulesoft.com/jms-connector/1.10/jms-publish-consume) --- product: JMS Connector version: 2.0 is-latest-version: true keywords: jms, connector, publish --- # Publish Messages Using JMS Connector > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The Anypoint Connector for JMS (JMS Connector) **Publish** operation enables you to create a new JMS message and send it to the specified destination, whether it is a queue or a topic. Using the operation, you can configure not only the content of the message, but also any necessary headers. ## Publish a Message to a Queue The **Publish** operation publishes whatever is in the message payload to the specified queue. In the following example, you configure the operation to publish a message to a queue specified in the **Destination** field: 1. In your Studio flow, select the **Publish** operation. 2. Set the **Destination** field to the queue name, for example, `invoiceQueue`. ![In the Publish configuration screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-publish-config-1.png) Figure 1. Publish operation configuration to a queue In the XML editor, the `` and `destination` configurations look like this: ```xml ``` If you must transform the payload because it is not in the correct format, you could place a DataWeave transformation before the **Publish** operation, but that would cause the message payload to change and impact the operation placed after the transformation. To avoid this impact, place the DataWeave transformation inside the **Publish** operation. The transformation generates the content to publish without affecting the message in transit. In the following example, you configure the transformation inside the operation: 1. In your Studio flow, select the **Publish** operation. 2. Set the **Destination** field to the queue name, for example, `invoiceQueue`. 3. In the **Body** field, set the following DataWeave transformation: ```DataWeave %dw 2.0 output application/json --- payload.payments ``` ![In the Publish configuration screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-publish-config-2.png) Figure 2. Publish operation configuration with DataWeave Transformation In the XML editor, the `` configuration looks like this: ```xml #[%dw 2.0 output application/json --- payload.payments ] ``` ## Publish a Message to a Topic The **Publish** operation can also publish a message to a specified topic destination. Because all the configurations of the operation and the message are identical, you just need only to configure the **Destination type** field to **TOPIC**. In the following example, you configure the operation to publish a message to a topic destination: 1. In your Studio flow, select the **Publish** operation. 2. Set the **Destination** field to the queue name, for example, .Publish operation configuration to a topic destination image::jms-publish-config-3.png\[In the Publish configuration screen, set the Destination type field to TOPIC\] In the XML editor, the `` and `destinationType` configurations look like this: ```xml #[%dw 2.0 output application/json --- payload.payments ] ``` ## Customize Message Delivery Each JMS message has a set of headers that enables you to communicate metadata such as the time to live or message priority. ### Configure a Priority Queue To configure a priority queue, set the **Priority** field to a value different from the default: 1. In your Studio flow, select the **Publish** operation. 2. Set the **Destination** field to the queue name, for example, `priorityQueue`. 3. In the **Publish Configuration** section, set the **Priority** field to `attributes.queryParams.priority`. ![In the Publish configuration screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-publish-config-4.png) Figure 3. Publish operation Priority configuration In the XML editor, the `` and `priority` configurations look like this: ```xml ``` ### Configure a Time To Live Every JMS message published is sent with a time-to-live header that declares how long the message is available for consumption it before it expires. In the operation, configure the **Time to live** and **Time to live unit** fields: 1. In your Studio flow, select the **Publish** operation. 2. Set the **Destination** field to the queue name, for example `vars.destination`. 3. In the **Publish Configuration** section, set the **Time to live** field to `vars.timeToLive`. 4. Set the **Time to live unit** field to **SECONDS**. ![In the Publish configuration screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-publish-config-5.png) Figure 4. Publish operation Time to live configuration In the XML editor, the `timeToLive` and `timeToLiveUnit` configurations looks like this: ```xml ``` If you are using the JMS 2.0 specification, you can also control the message delivery delay, which is how long to wait before making the message available to consumers. In the operation, configure the **Delivery delay** and **Delivery delay unit** fields: 1. In your Studio flow, select the **Publish** operation. 2. Set the **Destination** field to the queue name, for example, `vars.destination`. 3. Set the **Delivery delay** field to `${msgInitialDelay}`. 4. Set the **Delivery delay unit** field to **MILLISECONDS**. ![In the Publish configuration screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-publish-config-6.png) Figure 5. Publish operation Delivery Delay configuration In the XML editor, the `deliveryDelay` and `deliveryDelayUnit` configurations look like this: ```xml ``` ## Configure a Reply Destination When you require an asynchronous reply to the sent message, the **Publish** operation enables you to declare any reply-to destination in the **Reply to** field. The reply destination is communicated as a JMS header to the consumer of the message. In the following example, you configure the reply-to destination: 1. In your Studio flow, select the **Publish** operation. 2. Set the **Destination** field to the queue name, for example, `vars.destination`. 3. Set the **Reply to** field to **Edit inline**. 4. Set the **Destination name** field to `${completionEventsDestination}`. 5. Set the **Destination type** field to **TOPIC**. ![In the Publish configuration screen, set the Reply To to Edit inline, set a name for the Destination name field, and set the Destination type field to TOPIC.](/mulesoft/current/en-us/jms-connector/latest/_images/jms-publish-config-7.png) Figure 6. Publish operation Reply To configuration In the XML editor, the ``, `destination` and `destinationType` configurations look like this: ```xml ``` ## Configure the Correlation ID The **Publish** operation enables you to configure a correlation ID for the outgoing message in the **Correlation ID** field. First you must configure whether you want to send the correlation ID when publishing the message. If so, configure the **Send correlation id** field to any of the following options: - **ALWAYS** Always sends the header - **NEVER** Never sends the header - **AUTO** The default value, which uses the application configuration Then you can either use the correlation ID of the event that is sending the message, or you can configure your own custom correlation ID in the message builder: 1. In your Studio flow, select the **Publish** operation. 2. Set the **Destination** field to the queue name, for example, `attributes.headers.replyTo.destination`. 3. Set the **Send correlation id** field to **ALWAYS**. 4. Set the **Correlation ID** field to `attributes.headers.correlationId`. ![In the Publish configuration screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-publish-config-8.png) Figure 7. Publish operation Correlation ID configuration In the XML editor, the `endCorrelationId` and `correlationId` configurations look like this: ```xml ``` ## Configure Message Properties Use properties in your JMS message to do things like establishing compatibility with other messaging systems or creating custom message selectors Some of these properties are well-known JMS standards, but others depend on the implementation or custom user configurations. The **Publish** operation enables you to configure all these properties directly in the message. ### Configure User Properties Whenever you must set a property for an outgoing message, configure the **Properties** field in the message and perform an inline declaration of a map using DataWeave: 1. In your Studio flow, select the **Publish** operation. 2. Set the **Destination** field to the queue name, for example, `${bridgeDestination}`. 3. Set the **Destination type** field to **TOPIC**. 4. Set the **Body** field to `"bridged_" ++ payload`. 5. Set the **Properties** field to the following DataWeave code: ```DataWeave { AUTH_TYPE: 'jwt', AUTH_TOKEN: attributes.queryParams.token } ``` ![In the Publish configuration screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-publish-config-9.png) Figure 8. Publish operation Properties configuration In the XML editor, the `` and `` configurations look like this: ```xml #["bridged_" ++ payload] #[{ AUTH_TYPE: 'jwt', AUTH_TOKEN: attributes.queryParams.token }] ``` ### Configure JMSX Properties The JMS spec includes JMSX properties, a set well-known properties that contain metadata about the message. In the following example, you configure these properties in the **JMSX Properties** field of the message: 1. In your Studio flow, select the **Publish** operation. 2. Set the **Destination** field to the queue name, for example, `${bridgeDestination}`. 3. Set the **Destination type** field to **TOPIC**. 4. Set the **Body** field to `"bridged_" ++ payload`. 5. Set the **JMSX Properties** field to **Edit inline**. 6. Set the **Jmsx group id** field to `vars.currentGroup`. 7. Set the **Jmsx user id** field to `${username}`. ![In the Publish configuration screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-publish-config-10.png) Figure 9. Publish operation JMSX Properties configuration In the XML editor, the ``, `jmsxGroupID` and `jmsxUserID` configurations look like this: ```xml #["bridged_" ++ payload] ``` ## See Also [Publish Messages and Consume Replies](https://docs.mulesoft.com/jms-connector/latest/jms-publish-consume) --- product: JMS Connector version: 1.2 keywords: jms, connector, consume, message --- # To Consume JMS Messages > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The Consume operation in the JMS connector provides ability to consume a Message at any given time of the flow, from any given Destination. ## Consuming A Message The syntax to consume a message from a Queue is: ```xml ``` The operation above consumes the first available message in the Queue identified by the destination, and then converts it to a `MuleMessage` resulting in the following structure: - The message’s content as payload. - The message’s metadata in the message attributes. Once received, the Message will be immediately ACKed by default. If you want to control the ACK of the Message after some processing, then `ackMode` should be set to `MANUAL` For more information regarding a Message ACK, check the [How To Handle Message Acknowledgement](https://docs.mulesoft.com/jms-connector/1.2/jms-ack). ## Waiting for a Message By default, the maximum wait time is configured in 10 seconds, producing a `JMS:TIMEOUT` error if no message is available in that period. If order to configure a timeout that fits better your use case, customize the `maximumWait` and `maximumWaitUnit` parameters. In order to wait indefinitely for a Message to arrive, the `maximumWait` value has to be set to `-1`. In this case, no `TIMEOUT` error will be thrown. ## Polling for a Message When polling for a Message with a certain frequency, you don’t want the consumer to block waiting for the Message, but instead just try to consume it if one is present. In this cases, the `maximumWait` can be set to `0`, indicating that no waiting should occur, and neither a `JMS:TIMEOUT` should be thrown if no Message is available in the destination. The output of the `consume` operation will be `null` when no Message is present for consumption and no error is thrown. ## Filtering Incoming messages The JMS connector provides full support for filtering which Messages should be consumed based on the standard **JMS selector language**. For example, if you have a priority Queue with Messages that need to be processed faster than the others, we can do: ```xml ``` When a selector is configured, only the Messages matching it will be received, ignoring if any other Message is in the destination. ## Mime Types and Encoding The JMS Connector does its best to auto determine a Message’s mime type (`contentType`) based on the `MM_MESSAGE_CONTENT_TYPE` property. However, there are cases in which that best guess is not enough, and you need first-hand knowledge of the Message’s content. In such cases, you can force that content type to a particular value by using the `contentType` parameter. The same process works for encoding. By default, the connector will assume that the runtime’s default encoding matches the one in the Message if no other information is provided. You can set this by using the `encoding` parameter. ## Consuming A Message Using Topic Subscriptions Consuming messages from a Topic destination is very similar to consuming them from a Queue, but with the extra functionality of being able to use Topic subscriptions to share state between consumers. The syntax for consuming messages from a Topic is: ```xml ``` All the `consume` operation parameters remain the same, but now you can handle the subscription configuration in the `topic-consumer` parameter. For details on how to configure the Topic subscriptions go to [Using Topic Subscriptions](https://docs.mulesoft.com/jms-connector/1.2/jms-topic-subscription). ## Incoming Message Metadata As stated before, each Message received will consist of two parts: - The payload, containing the content of the Message - The attributes, containing metadata regarding the Message This Metadata has three parts that map all the information available in a JMS Message: - AckId - Headers - Properties ## See Also - [Using Topic Subscriptions](https://docs.mulesoft.com/jms-connector/1.2/jms-topic-subscription) - [To Listen For New Messages](https://docs.mulesoft.com/jms-connector/1.2/jms-listener) --- product: JMS Connector version: 1.2 keywords: jms, connector, consume, message, source, listener --- # To Listen For New Messages > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The On New Message (Listener) source in the JMS connector provides ability to consume Messages as they arrive to the Destination. ## Listening for New Messages The syntax to listen for new messages from a queue is: ```xml ``` The source above listens for new messages in the Queue identified by the destination, returning a `MuleMessage` each time a JMS Message is available in the Queue. The _MuleMessage_ will have: - The message’s content as payload. - The message’s metadata in the message attributes. By default, the Message consumed will be ACKed only when the execution of the flow receiving the message completes successfully. If instead, an error occurs during the execution of the flow, the Session will be recovered and the Message will be redelivered. For more information regarding a Message ACK, check the [How To Handle Message Acknowledgement](https://docs.mulesoft.com/jms-connector/1.2/jms-ack). ## Configuring Message Throughput When extra processing power is needed, the JMS Listener allows you to configure the `numberOfConsumers` that a given listener will use to consume messages concurrently. By default, each listener will use four consumers that will produce messages concurrently. Since each consumer will wait for the Message to be processed,that means that you’ll have a maximum of four messages in-flight at the same time. If you need to increase the concurrent message processing, just increase the `numberOfConsumers` in the Listener. ## Filtering Incoming messages The JMS connector provides full support for filtering which Messages should be consumed based on the standard JMS `selector` language. For example, if you have a priority Queue with Messages that need to be processed faster than the others, you can do: ```xml ``` When a selector is configured, only the Messages matching it will be received, ignoring if any other Message is in the destination. ## Mime Types and Encoding The JMS Connector does its best to auto determine a Message’s mime type (`contentType`) based on the `MM_MESSAGE_CONTENT_TYPE` property. However, there are cases in which that best guess is not enough, and you need first-hand knowledge of the Message’s content. In such cases, you can force that content type to a particular value by using the `inboundContentType` parameter. The same process works for encoding. By default, the connector will assume that the runtime’s default encoding matches the one in the Message if no other information is provided. You can set this by using the `inboundEncoding` parameter. ## Replying to Incoming Messages When an incoming JMS Message declares a REPLY\_TO destination, the JMS Listener will automatically produce a response **when the Message is processed successfully**, meaning that no error occurs during the flow execution. In that case, when the flow is completed a response will be published to the destination specified in the processed Message header. Responses can be configured in the Listener with the following syntax: ```xml #['Message received was: ' ++ payload] #[{'processedAt': now}] ``` This response builder allows you to configure not only the `body` and `properties` of the response message but also allows you to specify any header like `priority` and `persistentDelivery`. All these configurations impact in the outbound Message and can be built using all the information available in the flow when the processing is completed. Disable the automatic reply by using the `ignoreReplyTo` attribute in the `jms:response` element: ```xml ``` ## Listening for Messages with a Topic Subscription Listening for messages from a Topic destination is very similar to listening for them from a Queue, but with the extra functionality of being able to use Topic subscriptions to share state between consumers. The syntax for subscribing to a Topic is: ```xml ``` All the `listener` parameters remain the same, but now you can handle the subscription configuration in the `topic-consumer` parameter. For details on how to configure the Topic subscriptions go to [Using Topic Subscriptions](https://docs.mulesoft.com/jms-connector/1.2/jms-topic-subscription). ## 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) --- product: JMS Connector version: 1.2 keywords: jms, connector, publish --- # To Publish Messages > For the full documentation index, see: https://docs.mulesoft.com/llms.txt This operation allows you to create a new JMS Message and send it to the specified destination, be it a Queue or a Topic. With it, you can configure not only the content of the message, but also all the headers that may be need. ## Sending a Message to a Queue When used in its default form, the connector will publish whatever is in the message payload: ```xml ``` But what happens if the payload is not in the correct format, and you actually need to make a transformation? You could place a DataWeave transformation before the `publish` operation, but that would cause the message payload to change and impact the operation placed after the `publish` operation. To avoid this undesired impact, you can now place the transformation inside the `publish` operation: ```xml #[%dw 2.0 output application/json --- payload.payments ] ``` Now, the transformation can be used for generating the content that will be published, without producing a side effect on the message in transit. ## Publishing a Message to a Topic The `publish` operation can be used also to publish a Message to a given Topic destination. All the configurations of the operation and the Message are identical, but the `destinationType` parameter has to be declared as a `TOPIC` destination: For the same example seen before, if instead of sendin a message to the Queue we want to publish it to a Topic, we\`ll do: ```xml #[%dw 2.0 output application/json --- payload.payments ] ``` ## Customizing Message Delivery Each JMS Message has a set of headers that enables you to communicate metadata like the time to live, or the priority of the Message. This kind of metadata regarding the Message being published can be configured from the `publish` operation parameters. ### Implementing a Priority Queue In order to implement a priority queue, we need to assign a priority different than the default to some messages. We can do so using the `priority` parameter in the operation: ```xml ``` ### How to Control Message Time To Live Every JMS Message being published is sent with a timeToLive header that declares for how long the Message should be available for someone to consume it before it evicts. The `timeToLive` and `timeToLiveUnit` parameters in the `publish` operation allow you to configure the value of that JMS header for each Message published: ```xml ``` If you are using JMS 2.0, you can also control the `deliveryDelay` of the Message, which is how long to wait before making the Message available to consumers: ```xml ``` ## Declaring a Reply Destination For the cases where you need an asynchronous reply to the Message being sent, the JMS `publish` operation allows us to declare any `reply-to` destination. This destination will be communicated as a JMS Header to the consumer of the Message, and is the destination were we should expect a reply to be sent. To declare the `reply-to` destination, we add it to the Message definition: ```xml ``` ## Propagating The Correlation ID The `publish` operation allows you to configure what is the `correlationId` for the outgoing Message. First you need to configure whether or not you want to send the `correlationId` when publishing the Message using the `sendCorrelationId` parameter. This parameter can be set to `ALWAYS` (always send the header), `NEVER` (never send the header) or `AUTO` (the default, use the application configuration). Then, you can either use the `correlationId` of the Event that is sending the Message, or you can configure your own custom `correlationId` in the message builder: ```xml ``` ## Configuring Message Properties Every JMS Message can have a set of properties, which can be used in many different ways, like to provide compatibility with other messaging systems or create custom message selectors. Some of these properties are well-known JMS standards, but others depend on the implementation or custom user configurations. The `publish` operation allows you to configure all these properties directly in the Message. ### Setting User Properties Whenever you need to set a property for an outgoing Message, all you have to do is use the `properties` element in the Message and do an inline declaration of a Map using DataWeave: ```xml #["bridged_" ++ payload] #[{ AUTH_TYPE: 'jwt', AUTH_TOKEN: attributes.queryParams.token }] ``` ### Setting JMSX Properties The JMSX properties are a set of well-known properties defined in the JMS spec, containing metadata regarding the Message. In order to configure this properties, you can declare them inline as part of the Message element: ```xml #["bridged_" ++ payload] ``` ## See Also [To Listen For A Reply](https://docs.mulesoft.com/jms-connector/1.2/jms-publish-consume) --- product: JMS Connector version: 1.10 --- # Troubleshooting JMS Connector > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To troubleshoot Anypoint Connector for JMS (Java Message Service Connector), become familiar with the information about enabling verbose logging, troubleshooting acknowledgment issues, troubleshooting JMS 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 JMS server. To gather detailed logs: - Use the configuration file to increase the logging level on the server side. - Enable verbose logging for JMS Connector: 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 ``` ## 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 JMS Stopped Consuming Messages 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. ## 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. ## Troubleshoot HA Environments and Durable Subscriptions The configuration of HA (High Availability) systems consists of two components: - Primary node Is the main node that provides continuous service. - Secondary node Is a clone of the primary node and provides the same service. 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. ## Troubleshoot Prefetch Issues 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: ### Concurrent Flows Conditions - The same flow runs concurrently in two different threads of execution (thead A and thread B). - The JMS driver or broker prefetch size is configured to 10. - There are 100 messages in the queue. Flow iteration 1: - Thread A: consumer A is created, and there are 10 messages in its local buffer that are ready to process and be pushed by the broker (messages 1 to 10). - Thread B: consumer B is created, and there are 10 messages in its local buffer that are ready to process that were pushed by the broker (messages 11 to 20 because the first 10 messages were pushed to consumer A). - Thread A: consumer A acknowledged message 1, and messages 2 to 10 were returned to the broker. - Thread B: consumer B acknowledged message 11, and messages 12 to 20 were returned to the broker. - Messages 1 and 11 were consumed. Flow iteration 2: - Thread A: consumer A is created, and there are 10 messages in its local buffer that are ready to process and be pushed by the broker (messages 2,3,4,5,6,7,8,9,10,12). - Thread B: consumer B is created, and there are 10 messages in its local buffer that are ready to process that were pushed by the broker (messages 13 to 22). - Thread A: consumer A acknowledged message 2 and messages 3,4,5,6,7,8,9,10,12 were returned to the broker. - Thread B: consumer B acknowledged message 13 and messages 14 to 20 were returned to the broker. - Messages 2 and 13 were consumed. Flow iteration 3: - Thread A: consumer A is created, and there are 10 messages in its local buffer that are ready to process and be pushed by the broker (messages 3,4,5,6,7,8,9,10,12,14). - Thread B: consumer B is created, and there are 10 messages in its local buffer that are ready to process that were pushed by the broker (messages 15 to 24). - Thread A: consumer A acknowledged message 3 and messages 4,5,6,7,8,9,10,12,14 were returned to the broker. - Thread B: consumer B acknowledged message 15 and messages 16 to 24 were returned to the broker. - Messages 3 and 15 were consumed. Workaround: - Set the **Max Concurrency** field value of the flow to `1` to force the executions to be serialized, and the order of the consumed messages will be as expected. - Another option is to disable prefetch on the broker. Check your third-party JMS vendor provider documentation to disable prefetch. ### Multiple Consumes on the Same Flow Conditions - Messages are consumed in a foreach block from 1 to 4. - Messages consumed in the first point are added to a collection of messages that are later processed and acknowledged. - The JMS driver/broker prefetch size is configured to 2. - There are 4 messages in the queue. - The JMS **Consume** operation **Ack mode** field is configured to `MANUAL`, and messages are acknowledged in a foreach block using the collection created in the first point. Flow iteration 1: - Foreach iteration1 1: - Consumer 1 is created, and there are 2 messages in its local buffer that are ready to process and be pushed by the broker (messages 1 and 2). - Message 1 is added to the collection. - Foreach iteration 2: - Consumer 2 is created, and there are 2 messages in its local buffer that are ready to process and be pushed by the broker (messages 3 and 4). - Message 3 is added to the collection. - Foreach iteration 3: - No available messages in the queue. - Foreach iteration 4: - No available messages in the queue. Messages on the collection created by the foreach are acknowledged (1,3) and the rest of the messages are returned to the queue (2,4). Flow iteration 2: - Foreach iteration 1: - Consumer 1 is created, and there are 2 messages in its local buffer that are ready to process and be pushed by the broker (messages 2 and 4). - Message 2 is added to the collection. - Foreach iteration 2: - No available messages in the queue. - Foreach iteration 3: - No available messages in the queue. - Foreach iteration 4: - No available messages in the queue. Messages on the collection created by the foreach are acknowledged (2) and the rest of the messages are returned to the queue (4). Flow iteration 3: - Foreach iteration 1: - Consumer 1 is created, and there is 1 message in its local buffer that is ready to process and be pushed by the broker (message 4). - Message 4 is added to the collection. - Foreach iteration 2: - No available messages in the queue. - Foreach iteration 3: - No available messages in the queue. - Foreach iteration 4: - No available messages in the queue. Messages on the collection created by the foreach are acknowledged (4) Summarizing the flow iterations, the 3 iterations of the flow consume 4 messages in the queue and the order is not honored: - Iteration 1: \[1,3\] - Iteration 2: \[2\] - Iteration 3: \[4\] Workaround: - Disable prefetch on the broker, and check your third-party JMS vendor provider documentation to disable prefetch. - If you cannot disable prefetch on the broker, in the JMS **Consume** operation set the **Ack mode** field to `IMMEDIATE` to avoid holding the messages in the local buffer until the message is acknowledged. - Depending on the use case, use a JMS **On New Message** listener to process messages when they arrive instead of polling for messages using the JMS **Consume** operation. If you need to process messages in chunks, use the Aggregators module **Size based aggregator** scope to create a collection of messages for later processing. ## Troubleshoot ActiveMQ with JMS Connector When using ActiveMQ version 5.16.x and later, attempting to use an XAConnection (implemented by ActiveMQXAConnection) and an XASession (implemented by ActiveMQXASession) outside of a transaction results in a JMS exception message: `javax.jms.JMSException: Session’s XAResource has not been enlisted in a distributed transaction.` To resolve this issue, choose one of the these options: - Perform the XA enable operation within a transaction context. - Pass the `jms.xaAckMode=1` query parameter in the broker URL to execute an XA operation outside a transaction context. For example, for this broker URL: `vm://localhost?jms.xaAckMode=1` > [!NOTE] If you plan to use ActiveMQ version 5.16.x, use the ActiveMQ driver version 5.16.4 or > later. ## Understand Common Throws Here is a list of common throw messages and how to interpret them. - JMS:ACK There was an error in the context of the acknowledgment of an inflight message. - JMS:CONNECTIVITY The connection is no longer valid. It is disposed of, but you can apply a reconnection policy if defined in the application setup. - JMS:CONSUMING An error occurred while consuming messages from WMQ. This error might relate to the absence of a pending message. - JMS:DESTINATION\_NOT\_FOUND JMS Connector is not able to find or create the destination. - JMS:RETRY\_EXHAUSTED The maximum number of retries for the operation is reached. - JMS:SECURITY The thrown exception in due to of security-related errors. - JMS:TIMEOUT The timeout for the requested operation is exceeded. - JMS:ILLEGAL\_BODY The message body is invalid or cannot be converted to a supported type. - JMS:PUBLISHING There is an error while publishing to the target queue or topic. ## See Also - [JMS Connector Reference](https://docs.mulesoft.com/jms-connector/1.10/jms-connector-reference) - [Salesforce Help](https://help.salesforce.com) - [Known Issues](https://help.salesforce.com/s/issues) --- product: JMS Connector version: 2.0 is-latest-version: true --- # Troubleshooting JMS Connector > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To troubleshoot Anypoint Connector for JMS (Java Message Service Connector), become familiar with the information about enabling verbose logging, troubleshooting acknowledgment issues, troubleshooting JMS 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 JMS server. To gather detailed logs: - Use the configuration file to increase the logging level on the server side. - Enable verbose logging for JMS Connector: 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 ``` ## 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 JMS Stopped Consuming Messages 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. ## 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. ## Troubleshoot HA Environments and Durable Subscriptions The configuration of HA (High Availability) systems consists of two components: - Primary node Is the main node that provides continuous service. - Secondary node Is a clone of the primary node and provides the same service. 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. ## Troubleshoot Prefetch Issues 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: ### Concurrent Flows Conditions - The same flow runs concurrently in two different threads of execution (thead A and thread B). - The JMS driver or broker prefetch size is configured to 10. - There are 100 messages in the queue. Flow iteration 1: - Thread A: consumer A is created, and there are 10 messages in its local buffer that are ready to process and be pushed by the broker (messages 1 to 10). - Thread B: consumer B is created, and there are 10 messages in its local buffer that are ready to process that were pushed by the broker (messages 11 to 20 because the first 10 messages were pushed to consumer A). - Thread A: consumer A acknowledged message 1, and messages 2 to 10 were returned to the broker. - Thread B: consumer B acknowledged message 11, and messages 12 to 20 were returned to the broker. - Messages 1 and 11 were consumed. Flow iteration 2: - Thread A: consumer A is created, and there are 10 messages in its local buffer that are ready to process and be pushed by the broker (messages 2,3,4,5,6,7,8,9,10,12). - Thread B: consumer B is created, and there are 10 messages in its local buffer that are ready to process that were pushed by the broker (messages 13 to 22). - Thread A: consumer A acknowledged message 2 and messages 3,4,5,6,7,8,9,10,12 were returned to the broker. - Thread B: consumer B acknowledged message 13 and messages 14 to 20 were returned to the broker. - Messages 2 and 13 were consumed. Flow iteration 3: - Thread A: consumer A is created, and there are 10 messages in its local buffer that are ready to process and be pushed by the broker (messages 3,4,5,6,7,8,9,10,12,14). - Thread B: consumer B is created, and there are 10 messages in its local buffer that are ready to process that were pushed by the broker (messages 15 to 24). - Thread A: consumer A acknowledged message 3 and messages 4,5,6,7,8,9,10,12,14 were returned to the broker. - Thread B: consumer B acknowledged message 15 and messages 16 to 24 were returned to the broker. - Messages 3 and 15 were consumed. Workaround: - Set the **Max Concurrency** field value of the flow to `1` to force the executions to be serialized, and the order of the consumed messages will be as expected. - Another option is to disable prefetch on the broker. Check your third-party JMS vendor provider documentation to disable prefetch. ### Multiple Consumes on the Same Flow Conditions - Messages are consumed in a foreach block from 1 to 4. - Messages consumed in the first point are added to a collection of messages that are later processed and acknowledged. - The JMS driver/broker prefetch size is configured to 2. - There are 4 messages in the queue. - The JMS **Consume** operation **Ack mode** field is configured to `MANUAL`, and messages are acknowledged in a foreach block using the collection created in the first point. Flow iteration 1: - Foreach iteration1 1: - Consumer 1 is created, and there are 2 messages in its local buffer that are ready to process and be pushed by the broker (messages 1 and 2). - Message 1 is added to the collection. - Foreach iteration 2: - Consumer 2 is created, and there are 2 messages in its local buffer that are ready to process and be pushed by the broker (messages 3 and 4). - Message 3 is added to the collection. - Foreach iteration 3: - No available messages in the queue. - Foreach iteration 4: - No available messages in the queue. Messages on the collection created by the foreach are acknowledged (1,3) and the rest of the messages are returned to the queue (2,4). Flow iteration 2: - Foreach iteration 1: - Consumer 1 is created, and there are 2 messages in its local buffer that are ready to process and be pushed by the broker (messages 2 and 4). - Message 2 is added to the collection. - Foreach iteration 2: - No available messages in the queue. - Foreach iteration 3: - No available messages in the queue. - Foreach iteration 4: - No available messages in the queue. Messages on the collection created by the foreach are acknowledged (2) and the rest of the messages are returned to the queue (4). Flow iteration 3: - Foreach iteration 1: - Consumer 1 is created, and there is 1 message in its local buffer that is ready to process and be pushed by the broker (message 4). - Message 4 is added to the collection. - Foreach iteration 2: - No available messages in the queue. - Foreach iteration 3: - No available messages in the queue. - Foreach iteration 4: - No available messages in the queue. Messages on the collection created by the foreach are acknowledged (4) Summarizing the flow iterations, the 3 iterations of the flow consume 4 messages in the queue and the order is not honored: - Iteration 1: \[1,3\] - Iteration 2: \[2\] - Iteration 3: \[4\] Workaround: - Disable prefetch on the broker, and check your third-party JMS vendor provider documentation to disable prefetch. - If you cannot disable prefetch on the broker, in the JMS **Consume** operation set the **Ack mode** field to `IMMEDIATE` to avoid holding the messages in the local buffer until the message is acknowledged. - Depending on the use case, use a JMS **On New Message** listener to process messages when they arrive instead of polling for messages using the JMS **Consume** operation. If you need to process messages in chunks, use the Aggregators module **Size based aggregator** scope to create a collection of messages for later processing. ## Troubleshoot ActiveMQ with JMS Connector When using ActiveMQ version 5.16.x and later, attempting to use an XAConnection (implemented by ActiveMQXAConnection) and an XASession (implemented by ActiveMQXASession) outside of a transaction results in a JMS exception message: `javax.jms.JMSException: Session’s XAResource has not been enlisted in a distributed transaction.` To resolve this issue, choose one of the these options: - Perform the XA enable operation within a transaction context. - Pass the `jms.xaAckMode=1` query parameter in the broker URL to execute an XA operation outside a transaction context. For example, for this broker URL: `vm://localhost?jms.xaAckMode=1` > [!NOTE] If you plan to use ActiveMQ version 5.16.x, use the ActiveMQ driver version 5.16.4 or > later. ## Understand Common Throws Here is a list of common throw messages and how to interpret them. - JMS:ACK There was an error in the context of the acknowledgment of an inflight message. - JMS:CONNECTIVITY The connection is no longer valid. It is disposed of, but you can apply a reconnection policy if defined in the application setup. - JMS:CONSUMING An error occurred while consuming messages from WMQ. This error might relate to the absence of a pending message. - JMS:DESTINATION\_NOT\_FOUND JMS Connector is not able to find or create the destination. - JMS:RETRY\_EXHAUSTED The maximum number of retries for the operation is reached. - JMS:SECURITY The thrown exception in due to of security-related errors. - JMS:TIMEOUT The timeout for the requested operation is exceeded. - JMS:ILLEGAL\_BODY The message body is invalid or cannot be converted to a supported type. - JMS:PUBLISHING There is an error while publishing to the target queue or topic. ## See Also - [JMS Connector Reference](https://docs.mulesoft.com/jms-connector/latest/jms-connector-reference) - [Salesforce Help](https://help.salesforce.com) - [Known Issues](https://help.salesforce.com/s/issues) --- product: JMS Connector version: 1.10 keywords: jms, connector, consume, message, source, listener --- # Tune JMS Connector for Performance > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Performance is sometimes negatively impacted by message . The following recommendations can help you get the most of Anypoint Connector for JMS (JMS Connector) for your Mule applications. ## Connections Caching Reuse Because connections are expensive to create, reuse them as much as you can. By default, JMS Connector uses a caching strategy that reuses as many consumers and producers as possible. To avoid performance degradation, do not disable connection caching. ## Increased Concurrent Messages Processing To improve the performance of your application, increase the number of consumers that receive messages from the same destination. JMS Connector enables you to increase the number of consumers by configuring the **Number of consumers** field in the **On New Message** source. By default, this source enables four consumers to receive messages concurrently on the same destination, but you can increase this number to the one that best fits your needs. In the following example, you increase the number of consumers receiving messages concurrently: 1. In Studio, select the **On New Message** source from your flow. 2. In the **On New Message** source configuration screen, set the **Number of consumers** field to `20`. ![In the On New Message configuration screen](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-performance-1.png) Figure 1. JMS Connector Number of consumers Configuration In the XML editor, the `numberOfConsumers` configuration looks like this: ```xml ``` ## Cluster Configuration Optimization For applications running in clusters, consider the primary node and how the connector behaves. When the app runs in a cluster, the **On New Message** source default behavior receives messages only in the primary node, no matter what kind of destination the app consumes. When consuming messages from a queue, the default connector behavior is to receive messages in all the cluster’s nodes, not just the primary node. JMS Connector enables you to configure the **Primary node only** field in the **On New Message** source. When the connector consumes from a queue in a cluster, do not select the **Primary node only** field, which defaults to `false`. In the following example, you configure the connector to receive messages in all the nodes: 1. In Studio, select the **On New Message** source from your flow. 2. In the **Advanced** tab, leave unselected the **Primary node only** field. ![In the Advanced tab of the On New Message source](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-performance-2.png) Figure 2. JMS Connector Primary Node only Configuration In the XML editor, the `primaryNodeOnly` configuration looks like this: ```xml ``` When consuming messages from a topic, the default connector behavior is to receive messages only in the primary node, which avoids processing the same message multiple times across the cluster. When consuming messages from a topic in a cluster, the configuration of **Primary node only** unselected causes the cluster to process the same message more than once, unless you also configure shared subscriptions. If you are using the JMS 2.0 shared subscriptions mechanism, then change the cluster configuration to consume from all the nodes, again setting the **Primary node only** field to `false`. In the following example, you configure the connector using 2.0 spec shared-subscriptions mechanism: 1. In Studio, select the **On New Message** source from your flow. 2. In the **On New Message** source configuration screen, select **Topic consumer**. 3. Select the **Shared** option. 4. Set the **Subscription name** to `clusteredEventListener`. 5. In the **Advanced** tab, leave unselected the **Primary node only** field. ![In the Advanced tab of the On New Message source](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-performance-3.png) Figure 3. JMS Connector Primary Node only Configuration In the XML editor, the `jms:topic-consumer`, `shared`, and `primaryNodeOnly` configurations look like this: ```xml ``` ## Configure Prefetch for JMS Connector For JMS Connector, when using ActiveMQ client, you configure prefetch on the server connection URL. Refer to the [ActiveMQ documentation](https://activemq.apache.org/components/classic/documentation/what-is-the-prefetch-limit-for#:~:text=Specifying%20the%20PrefetchPolicy) for details. For example, consider these connection URLs with the `jms.prefetchPolicy.all` parameter: ```xml tcp://localhost:61616?jms.prefetchPolicy.all=50 tcp://localhost:61616?jms.prefetchPolicy.queuePrefetch=1 ``` In the JMS Connector XML configuration, the configuration of the connection `brokenUrl` looks like this: ```xml ``` Increase prefetch values for high performance with high message volumes. However, for lower message volumes, where each message takes a long time to process, set the prefetch to `1`. This ensures that a consumer is only processing one message at a time. Specifying a prefetch limit of zero, however, causes the consumer to poll for messages, one at a time, instead of the message being pushed to the consumer. ## See Also - [Consume Messages](https://docs.mulesoft.com/jms-connector/1.10/jms-consume) - [Configure Topic Subscriptions](https://docs.mulesoft.com/jms-connector/1.10/jms-topic-subscription) --- product: JMS Connector version: 2.0 is-latest-version: true keywords: jms, connector, consume, message, source, listener --- # Tune JMS Connector for Performance > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Performance is sometimes negatively impacted by message . The following recommendations can help you get the most of Anypoint Connector for JMS (JMS Connector) for your Mule applications. ## Connections Caching Reuse Because connections are expensive to create, reuse them as much as you can. By default, JMS Connector uses a caching strategy that reuses as many consumers and producers as possible. To avoid performance degradation, do not disable connection caching. ## Increased Concurrent Messages Processing To improve the performance of your application, increase the number of consumers that receive messages from the same destination. JMS Connector enables you to increase the number of consumers by configuring the **Number of consumers** field in the **On New Message** source. By default, this source enables four consumers to receive messages concurrently on the same destination, but you can increase this number to the one that best fits your needs. In the following example, you increase the number of consumers receiving messages concurrently: 1. In Studio, select the **On New Message** source from your flow. 2. In the **On New Message** source configuration screen, set the **Number of consumers** field to `20`. ![In the On New Message configuration screen](/mulesoft/current/en-us/jms-connector/latest/_images/jms-performance-1.png) Figure 1. JMS Connector Number of consumers Configuration In the XML editor, the `numberOfConsumers` configuration looks like this: ```xml ``` ## Cluster Configuration Optimization For applications running in clusters, consider the primary node and how the connector behaves. When the app runs in a cluster, the **On New Message** source default behavior receives messages only in the primary node, no matter what kind of destination the app consumes. When consuming messages from a queue, the default connector behavior is to receive messages in all the cluster’s nodes, not just the primary node. JMS Connector enables you to configure the **Primary node only** field in the **On New Message** source. When the connector consumes from a queue in a cluster, do not select the **Primary node only** field, which defaults to `false`. In the following example, you configure the connector to receive messages in all the nodes: 1. In Studio, select the **On New Message** source from your flow. 2. In the **Advanced** tab, leave unselected the **Primary node only** field. ![In the Advanced tab of the On New Message source](/mulesoft/current/en-us/jms-connector/latest/_images/jms-performance-2.png) Figure 2. JMS Connector Primary Node only Configuration In the XML editor, the `primaryNodeOnly` configuration looks like this: ```xml ``` When consuming messages from a topic, the default connector behavior is to receive messages only in the primary node, which avoids processing the same message multiple times across the cluster. When consuming messages from a topic in a cluster, the configuration of **Primary node only** unselected causes the cluster to process the same message more than once, unless you also configure shared subscriptions. If you are using the JMS 2.0 shared subscriptions mechanism, then change the cluster configuration to consume from all the nodes, again setting the **Primary node only** field to `false`. In the following example, you configure the connector using 2.0 spec shared-subscriptions mechanism: 1. In Studio, select the **On New Message** source from your flow. 2. In the **On New Message** source configuration screen, select **Topic consumer**. 3. Select the **Shared** option. 4. Set the **Subscription name** to `clusteredEventListener`. 5. In the **Advanced** tab, leave unselected the **Primary node only** field. ![In the Advanced tab of the On New Message source](/mulesoft/current/en-us/jms-connector/latest/_images/jms-performance-3.png) Figure 3. JMS Connector Primary Node only Configuration In the XML editor, the `jms:topic-consumer`, `shared`, and `primaryNodeOnly` configurations look like this: ```xml ``` ## Configure Prefetch for JMS Connector For JMS Connector, when using ActiveMQ client, you configure prefetch on the server connection URL. Refer to the [ActiveMQ documentation](https://activemq.apache.org/components/classic/documentation/what-is-the-prefetch-limit-for#:~:text=Specifying%20the%20PrefetchPolicy) for details. For example, consider these connection URLs with the `jms.prefetchPolicy.all` parameter: ```xml tcp://localhost:61616?jms.prefetchPolicy.all=50 tcp://localhost:61616?jms.prefetchPolicy.queuePrefetch=1 ``` In the JMS Connector XML configuration, the configuration of the connection `brokenUrl` looks like this: ```xml ``` Increase prefetch values for high performance with high message volumes. However, for lower message volumes, where each message takes a long time to process, set the prefetch to `1`. This ensures that a consumer is only processing one message at a time. Specifying a prefetch limit of zero, however, causes the consumer to poll for messages, one at a time, instead of the message being pushed to the consumer. ## See Also - [Consume Messages](https://docs.mulesoft.com/jms-connector/latest/jms-consume) - [Configure Topic Subscriptions](https://docs.mulesoft.com/jms-connector/latest/jms-topic-subscription) --- product: JMS Connector version: 2.0 is-latest-version: true --- # Upgrading and Migrating JMS Connector to Version 2.x > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Upgrade Anypoint Connector for JMS (JMS Connector) to version 2.x. ## Supported Upgrade Paths
From VersionTo Version

1.x

2.x

## Changes in This Release JMS Connector 2.x contains the following changes: - This connector is now compatible with Java 17 only. - The **Enable xa** field is removed from the ActiveMQ connection factory configuration. - JMS Connector provides separate connection types for XA and non-XA transactions. You can now select the new **ActiveMQ XA Connection** or **Generic XA Connection** type in the **JMS Config** window. These new connection types replace the previous **Enable xa** toggle on a single connection. - The existing **ActiveMQ Connection** and **Generic Connection** types are now used only for non-XA scenarios. - The deprecated **ActiveMQ Connection - No Connectivity Test** connection type is removed. There is no replacement connection type. Use **ActiveMQ Connection** instead. - The **XA connection pool** configuration (**Max pool size** and **Max idle seconds**) now applies only to the XA connection types. The **Min pool size** field no longer exists. - These libraries are upgraded: - The `jakarta.jms-api` library is upgraded to version 3.1.0, replacing `javax.jms-api`. - The Spring framework is upgraded to version 6.2.15. - The Apache ActiveMQ library is upgraded to version 6.1.0. - The Apache ActiveMQ Artemis library is upgraded to version 2.50.0. In version 1.x, you configured XA transactions on the standard ActiveMQ connection: ```xml ``` In version 2.x, configure XA transactions using the new **ActiveMQ XA Connection** connection type: ```xml ``` Non-XA connections that use the **ActiveMQ Connection** type require no changes. If your application uses the removed **ActiveMQ Connection - No Connectivity Test** type, switch to **ActiveMQ Connection** (or **ActiveMQ XA Connection**, if the application also requires XA transactions). ## Requirements Ensure your system meets the following compatibility requirements before you perform the upgrade:
Application/ServiceVersion

Mule runtime

4.10.0 and later

Java

17

## Upgrade Prerequisites Before you perform the upgrade, create a backup of your files, data, and configuration in case you need to restore to the previous version. ## Upgrade Steps Follow these steps to perform the upgrade to version 2.x: 1. In Anypoint Studio, create a Mule project. 2. In the **Mule Palette** view, click **Search in Exchange**. 3. In **Add Dependencies to Project**, enter `jms` in the search field. 4. In **Available modules**, select **JMS Connector** and click **Add**. 5. Click **Finish**. 6. Verify that the JMS Connector dependency version is `2.x` in the project’s `pom.xml` file. Studio upgrades the connector automatically. ## Post-Upgrade Steps After you install the latest version of the connector, complete the following steps if your application uses XA transactions: 1. In each **JMS Config** global element that uses XA transactions, change the **Connection** field to the corresponding XA connection type: - **ActiveMQ Connection** → **ActiveMQ XA Connection** - **Generic Connection** → **Generic XA Connection** 2. Move any **XA connection pool** configuration (**Max pool size** and **Max idle seconds**) to the new XA connection element. Remove any **Min pool size** value, because this field no longer exists. 3. Remove any reference to the **Enable Xa** field, if present, because it no longer exists on the ActiveMQ connection factory configuration. 4. If any **JMS Config** global element uses the removed **ActiveMQ Connection - No Connectivity Test** connection type, change the **Connection** field to **ActiveMQ Connection** (or **ActiveMQ XA Connection** if the application also requires XA transactions). For more information, see [Configuring XA Transactions in JMS Connector](https://docs.mulesoft.com/jms-connector/latest/jms-xa-transactions). ## Verify the Upgrade After you install the latest version of the connector, follow these steps to verify the upgrade: 1. In Studio, verify that there are no errors in the **Problems** or **Console** views. 2. Verify that there are no problems in the project `pom.xml` file. 3. Test the connection to verify that the operations work. 4. If your app uses XA transactions, verify that the corresponding XA connection type is configured and that transactions still commit and roll back as expected. ## Revert the Upgrade If it is necessary to revert to the previous version of JMS Connector, change the `mule-jms-connector` dependency version in the project’s `pom.xml` file to the previous version, and revert any XA connection elements back to their equivalent non-XA connection type with the **Enable Xa** field set. If you switched away from the removed **ActiveMQ Connection - No Connectivity Test** connection type as part of the upgrade, you can restore it after reverting. You must update the project’s `pom.xml` file in Anypoint Studio. ## See Also - [Configuring XA Transactions in JMS Connector](https://docs.mulesoft.com/jms-connector/latest/jms-xa-transactions) - [Configure an ActiveMQ Connection for JMS Connector](https://docs.mulesoft.com/jms-connector/latest/jms-activemq-configuration) - [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors) - [Salesforce Help](https://help.salesforce.com) --- product: JMS Connector version: 1.10 --- # Using Anypoint Studio to Configure JMS Connector 1.10 > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Studio (Studio) editors help you design and update your Mule applications, properties, and configuration files. To add and configure a connector in Studio: 1. [Create a Mule project](#create-mule-project). 2. [Add the connector to your Mule project](#add-connector-to-project). 3. [Configure a source for the connector’s flow](#configure-input-source). 4. [Add a connector operation to the flow](#add-connector-operation). 5. [Configure a global element for the connector](#configure-global-element). 6. [Configure the connection to a broker](#configure-connection). When you run the connector, you can view the app log to check for problems, as described in [View the App Log](#view-app-log). If you are new to configuring connectors in Studio, see [Using Anypoint Studio to Configure a Connector](https://docs.mulesoft.com/connectors/introduction/intro-config-use-studio). If, after reading this topic, you need additional information about the connector fields, see the [JMS Connector Reference](https://docs.mulesoft.com/jms-connector/1.10/jms-connector-reference). ## Create a Mule Project In Studio, create a new Mule project in which to add and configure the connector: 1. In Studio, select **File > New > Mule Project**. 2. Enter a name for your Mule project and click **Finish**. ## Add the Connector to Your Mule Project Add Anypoint Connector for JMS (JMS Connector) to your Mule project to automatically populate the XML code with the connector’s namespace and schema location and to add the required dependencies to the project’s `pom.xml` file: 1. In the **Mule Palette** view, click **(X) Search in Exchange**. 2. In the **Add Dependencies to Project** window, type `jms` in the search field. 3. Click **JMS Connector** in **Available modules**. 4. Click **Add**. 5. Click **Finish**. Adding a connector to a Mule project in Studio does not make that connector available to other projects in your Studio workspace. ## Configure a Source A source initiates a flow when a specified condition is met. You can configure one of these input sources to use with JMS Connector: - **JMS > On New Message** Initiates a flow by listening for incoming messages - **HTTP > Listener** Initiates a flow each time it receives a request on the configured host and port - **Scheduler** Initiates a flow when a time-based condition is met For example, to configure an **On New Message** source, follow these steps: 1. In the **Mule Palette** view, select **JMS > On New Message**. 2. Drag **On New Message** to the Studio canvas. 3. In the **On New Message** configuration screen, optionally change the value of the **Display Name** field. 4. Click the plus sign (**+**) next to the **Connector configuration** field to configure a global element that can be used by all instances of the source in the app. 5. In the **JMS Config** window, for **Connection**, select either one of the connection types to provide to this configuration: - **Active MQ Connection** - **Active MQ Connection -No Connectivity Test -** (DEPRECATED) - **Generic Connection** 6. On the **General** tab, specify the connection information for the connector, such as required libraries for the broker, JMS specification, cache strategy, authentication, and connection factory. 7. On the **TLS/SSL** tab, optionally specify a TLS configuration. 8. On the **Advanced** tab, optionally specify a reconnection strategy and XA connection pool. 9. Click **OK** to close the window. 10. In the **On New Message** configuration screen, in **Destination**, specify the name of the destination from where to consume the message. 11. Configure other optional fields in the **On New Message** configuration screen. ## Add a Connector Operation to the Flow When you add a connector operation to your flow, you immediately define a specific operation for that connector to perform. To add an operation for JMS Connector, follow these steps: 1. In the **Mule Palette** view, select **JMS Connector** and then select the desired operation. 2. Drag the operation onto the Studio canvas and to the right of the input source. The following screenshot shows the JMS Connector operations in the Mule Palette view of Anypoint Studio: ![Select any of the JMS Connector Operations from the Mule Palette view on the right side of Anypoint Studio](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-operations.png) Figure 1. JMS Connector Operations ## Configure a Global Element for the Connector To avoid connectivity issues, create separate JMS configurations for publishing and consuming, instead of creating a shared JMS configuration for both publishing and consuming. JMS Connector comes with a fine-tuned set of default values for publishing and consuming messages. The only requirement is to configure which connection to use. You can define a global default behavior for all the operations associated with the configuration and then override each parameter in only the operations that require a custom behavior. To configure the global element for JMS Connector, follow these steps: 1. Select the operation in the Studio canvas. 2. In the configuration screen for the operation, click the plus sign (**+**) next to the **Connector configuration** field to access the global element configuration fields. 3. In the **JMS Config** window, for **Connection**, select either one of the connection types to provide to this configuration: - **Active MQ Connection** - **Active MQ Connection -No Connectivity Test -** (DEPRECATED) - **Generic Connection** 4. On the **General** tab, specify the connection information for the connector, such as required libraries for the broker, JMS specification, cache strategy, authentication, and connection factory. 5. On the **TLS/SSL** tab, optionally specify a TLS configuration. 6. On the **Advanced** tab, optionally specify a reconnection strategy, and XA connection pool. 7. On the **Consumer** tab, optionally define global default behavior configurations for all the **Consume** and **On New Message** operations you have in your flow. 8. On the **Producer** tab, optionally define global default behavior configurations for all the **Publish** and **Publish consume** operations you have in your flow. 9. Click **OK** to close the window. The following screenshot shows the JMS Connector **Global Element Configuration** window in Anypoint Studio: ![JMS Connector Global Element Configuration window](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-global-configuration.png) Figure 2. JMS Connector Global Element Configuration In the XML editor, the `` configuration looks like this: ```xml ``` In the following example, you define a default **Selector** behavior when consuming a message in any of the **Consume** or **On New Message** operations associated with this configuration, while every **Publish** or **Publish consume** operation produces the outgoing message with a **Time to live** (TTL) of 60 seconds: 1. In Studio, navigate to the **Global Elements** tab. 2. Click **Create**. 3. In the filter box type `jms` and select **JMS Config**. 4. Click **OK**. 5. In the **JMS Config** window, for **Connection**, select **Active MQ Connection**. 6. In the **Consumer** tab, set the **Selector** field to ``JMSType = `INVOICE`` to filter incoming messages as invoices. ![In the Consumer tab](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-global-configuration-consumer.png) Figure 3. JMS Connector Consumer Global Configuration 5. In the **Producer** tab, set the **Time to live** field to `60000` to define the default time the message is in the broker before it expires and is discarded. ![In the Producer tab](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-global-configuration-producer.png) Figure 4. JMS Connector Producer Global Configuration In the XML editor, the ``,`selector`, and `timeToLive` configurations looks like this: ```xml ``` You can override these properties at the operation level when required. In the following example, you publish a message with a shorter TTL. To override the value of the **Time to live** field set on the global element, follow these steps: 1. In Studio, select the **Publish** operation from your flow. 2. In the **Publish** configuration screen, scroll down to the **Publish Configuration** section. 3. Set the **Time to live** field to `10000` to override the default global configuration previously set. ![In the Publish Configuration section](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-publish-configuration-1.png) Figure 5. JMS Connector Publish Configuration Override In the XML editor, the `` and `timeToLive` configurations looks like this: ```xml ``` ## Configure the Connection to a Broker To configure the connection in the global element, define the connection by selecting either **ActiveMQ Connection** or **Generic Connection** and set up the connection libraries and the JMS specification. JMS Connector also enables you to provide credentials, if you require an authenticated connection, and also to configure connection caching to increase the performance of the application. ### Configure an Active MQ Connection JMS Connector supports ActiveMQ 5 by using the **ActiveMQ Connection** setting. With this connection, you can use `JMS_1_1 (Default)` or `JMS_1_0_2b` specifications. You can also configure all the general connection parameters for JMS, as well as the custom parameters present only in ActiveMQ. After you declare the ActiveMQ connection, customize **Connection Factory** to your desired configuration. Every parameter in the connection comes with a default value, meaning that you are required to configure only the parameters relevant for your use case. Also, the ActiveMQ connection exposes parameters that are exclusive to the ActiveMQ implementation, like **Initial redelivery delay**. In the following example, you configure an **ActiveMQ Connection**: 1. In Studio, navigate to the **Global Elements** tab. 2. Click **Create**. 3. In the filter box type `jms` and select **JMS Config**. 4. Click **OK**. 5. In the **Connection** field select **ActiveMQ Connection**. 6. In the **Factory configuration** field, select **Edit Inline**. 7. Set the **Broker url** field value to the address of the broker to connect to, for example, `tcp://localhost:61616`. 8. Click **OK**. ![ActiveMQ Connection Configuration.](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-activemq-configuration.png) Figure 6. JMS Connector ActiveMQ Configuration In the XML editor, the `` and `` configuration looks like this: ```xml ``` ### Configure a Generic Connection Use **Generic Connection** to configure a connection to any broker implementation. JMS Connector provides a JNDI based (Java Naming and Directory Interface) connection factory builder that enables you to configure the connection using JNDI in the context of the application. In the following example, you configure **Generic Connection** to Artemis to use the `JMS_2_0` specification using JNDI: 1. In Studio, navigate to the **Global Elements** tab. 2. Click **Create**. 3. In the filter box, type `jms` and select **JMS Config**. 4. Click **OK**. 5. In the **Connection** field, select **Generic Connection**. 6. In the **Specification** field, select **JMS\_2\_0**. 7. In the **Connection factory** field, select **Edit inline**. 8. Set the **Connection factory jndi name** field to `ConnectionFactory`. 9. In the **Lookup destination** field, select any of the following options: - **NEVER** No lookup is done and the destinations are created using the existing JMS session. - **TRY\_ALWAYS** Tries to find the destination using JNDI, and in case it doesn’t exist, creates the destination using the current JMS session. - **ALWAYS** If a queue or topic cannot be found via JNDI, the lookup fails with a `JMS:DESTINATION_NOT_FOUND` error. 10. Select the **Name resolver builder** field. 11. Set the **Jndi initial context factory** field to `org.apache.activemq.artemis.ActiveMQInitialContextFactory`. 12. Set the **Jndi provider url** field to `tcp://localhost:61616?broker.persistent=false&broker.useJmx=false`. 13. Set **Provider properties** to **Edit inline**. 14. Click the plus sign (**+**) to add a new provider property. 15. In the **Provider property** window, set the **Key** field to `queue.jndi-queue-in` and the **Value** field to `in.queue`. 16. Click **Finish**. 17. Repeat Step 14. 18. Set the **Key** field to `topic.jndi-topic-in` and the **Value** field to `in.topic`. 19. Click **OK**. ![Generic Connection Configuration.](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-generic-configuration.png) Figure 7. JMS Connector Generic Configuration In the XML editor, the `` and `` configuration looks like this: ```xml ``` ### Configure the Connection Libraries When you configure any connection type, you must always configure a library containing the JMS client implementation, because JMS Connector is not bound to any particular implementation. You can configure ActiveMQ external libraries and generic external libraries found in the global elements view of Studio, you can manually add the library dependency in your `pom.xml` file. #### ActiveMQ External Libraries For an **ActiveMQ Connection**, you can configure three libraries: - **ActiveMQ KahaDB** The `activemq-kahadb-store` dependency is required only when using an persistent in-memory broker based on the VM transport (such as `vm://localhost?broker.persistent=true`). This dependency provides a valid `org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter` implementation. In your `pom.xml` file in Studio, adding the dependency looks like this: ```xml org.apache.activemq activemq-kahadb-store 5.14.4 ``` - **ActiveMQ Broker** The `activemq-broker` dependency is required only when using an in-memory broker based on the VM transport (which is the one configured by default). This dependency provides a valid `org.apache.activemq.broker.Broker` implementation. In your `pom.xml` file in Studio, adding the dependency looks like this: ```xml org.apache.activemq activemq-broker 5.14.4 ``` - **ActiveMQ Client** The `activemq-client` dependency is always required. Choose one that provides a valid `org.apache.activemq.ActiveMQConnectionFactory` implementation. In your `pom.xml` file in Studio, adding the dependency looks like this: - ```xml org.apache.activemq activemq-client 5.14.4 ``` To configure these libraries in the Global Element view, follow these steps: 1. In Studio, navigate to the **Global Elements** tab. 2. Click **Create**. 3. In the filter box, type `jms` and select **JMS Config**. 4. Click **OK**. 5. In the **Connection** field, select **ActiveMQ Connection**. 6. In the **Required Libraries** section that shows the **ActiveMQ KahaDB**, **ActiveMQ Broker** and **ActiveMQ Client** libraries, click the **Configure…​** button to install the dependency. 7. Select any of the following install options: - **Add recommended library** Installs the recommended library. - **Use local file** Browse to a local file for the required engine library and install it. - **Add Maven dependency** Browse to the dependency and install it. #### Generic External Libraries For **Generic Connection**, provide all the libraries that the connection factory of your implementation requires. Ensure that you supply all the required dependencies to the application. In the following example, you configure a generic library for a connection that uses a JMS 2.0 specification, which requires a generic connection with a different client library, like Apache Artemis: In your `pom.xml` file in Studio, adding the dependency looks like this: ```xml org.apache.activemq artemis-jms-client-all 2.17.0 ``` To configure these libraries in the Global Element view, follow these steps: 1. In Studio, navigate to the **Global Elements** tab. 2. Click **Create**. 3. In the filter box, type `jms` and select **JMS Config**. 4. Click **OK**. 5. In the **Connection** field, select **Generic Connection**. 6. In the **Required Libraries** section that shows the **JMS Client**, click the **Configure…​** button to install the dependency. 7. Select any of the following install options: - **Add recommended library** Installs the recommended library. - **Use local file** Browse to a local file for the required engine library and install it. - **Add Maven dependency** Browse to the dependency and install it. ### Configure the JMS Specification The JMS **Specification** you configure must be supported by the broker implementation associated with the connection; otherwise, the connection fails. Note that features that are available only in `JMS_2_0` won’t work with any other specification. To configure the JMS specification in Studio, follow these steps: 1. In Studio, open the **JMS Config** global element window. 2. In the **Specification** field, select one of the following supported specifications: - **JMS\_1\_1 (Default)** - **JMS\_1\_0\_2b** - **JMS\_2\_0** 3. Click **OK**. ![In the Specification field select one of the supported specifications](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-spec-config.png) Figure 8. JMS Connector specification configuration In the XML editor, the `specification` configuration looks like this: ```xml ``` ### Configure Connection Caching To connect with a broker and execute required operations, JMS Connector creates multiple sessions of consumers and producers that can be cached and reused to increase application performance. JMS Connector enables you to configure the **Caching strategy** field to use when creating new connections. By default, both consumers and producers are cached and as many concurrent instances are cached in memory. Do not disable the sessions cache by using the **No caching** configuration, which is used only with a custom connection factory that already manages its own cache. In the following example you configure the caching strategy: 1. In Studio, open the **JMS Config** global element window. 2. In the **Caching strategy** field, select **Default caching (Default)**. 3. Set the **Session cache size** field to `100`. 4. Select **Cache producers**. 5. Click **OK**. ![In the Caching strategy field select the desired caching strategy](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-caching-config.png) Figure 9. JMS Connector caching strategy configuration In the XML editor, the `` and `` configuration looks like this: ```xml ``` In the following XML example, the `` configuration looks like this: ```xml ``` ### Configure the Client Identifier and Credentials for Authentication The client identifier associates a connection and its objects with a state that is maintained on behalf of the client by a provider. It is mandatory for identifying an unshared durable subscription. Note that the client state identified in the **Client id** can be used by only one connection at a time. In the following example, you configure an authenticated connection and the client identifier: 1. In Studio, open the **JMS Config** global element window. 2. In the **Connection** section, set the **Username** field to `${env.user}` and the **Password** field to `${env.pass}`. 3. Set the **Client id** field to `${env.clientId}`. 4. Click **OK**. ![In the Connection section, set the Username, Password, and Client id fields.](/mulesoft/current/en-us/jms-connector/1.10/_images/jms-authentication-config.png) Figure 10. JMS Connector authenticated connection and client identifier configuration In the XML editor, the `username`, `password`, and `clientId` configuration looks like this: ```xml ``` ## View the App Log To check for problems, you can view the app log as follows: - If you’re running the app from Anypoint Platform, the output is visible in the Anypoint Studio console window. - If you’re running the app using Mule from the command line, the app log is visible in your OS console. Unless the log file path is customized in the app’s log file (`log4j2.xml`), you can also view the app log in the default location `MULE_HOME/logs/.log`. ## See Also - [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors) - [Using Anypoint Studio to Configure a Connector](https://docs.mulesoft.com/connectors/introduction/intro-config-use-studio) - [JMS Connector Reference](https://docs.mulesoft.com/jms-connector/1.10/jms-connector-reference) - [Salesforce Help](https://help.salesforce.com) --- product: JMS Connector version: 2.0 is-latest-version: true --- # Using Anypoint Studio to Configure JMS Connector 2.0 > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Studio (Studio) editors help you design and update your Mule applications, properties, and configuration files. To add and configure a connector in Studio: 1. [Create a Mule project](#create-mule-project). 2. [Add the connector to your Mule project](#add-connector-to-project). 3. [Configure a source for the connector’s flow](#configure-input-source). 4. [Add a connector operation to the flow](#add-connector-operation). 5. [Configure a global element for the connector](#configure-global-element). 6. [Configure the connection to a broker](#configure-connection). When you run the connector, you can view the app log to check for problems, as described in [View the App Log](#view-app-log). If you are new to configuring connectors in Studio, see [Using Anypoint Studio to Configure a Connector](https://docs.mulesoft.com/connectors/introduction/intro-config-use-studio). If, after reading this topic, you need additional information about the connector fields, see the [JMS Connector Reference](https://docs.mulesoft.com/jms-connector/latest/jms-connector-reference). ## Create a Mule Project In Studio, create a new Mule project in which to add and configure the connector: 1. In Studio, select **File > New > Mule Project**. 2. Enter a name for your Mule project and click **Finish**. ## Add the Connector to Your Mule Project Add Anypoint Connector for JMS (JMS Connector) to your Mule project to automatically populate the XML code with the connector’s namespace and schema location and to add the required dependencies to the project’s `pom.xml` file: 1. In the **Mule Palette** view, click **(X) Search in Exchange**. 2. In the **Add Dependencies to Project** window, type `jms` in the search field. 3. Click **JMS Connector** in **Available modules**. 4. Click **Add**. 5. Click **Finish**. Adding a connector to a Mule project in Studio does not make that connector available to other projects in your Studio workspace. ## Configure a Source A source initiates a flow when a specified condition is met. You can configure one of these input sources to use with JMS Connector: - **JMS > On New Message** Initiates a flow by listening for incoming messages - **HTTP > Listener** Initiates a flow each time it receives a request on the configured host and port - **Scheduler** Initiates a flow when a time-based condition is met For example, to configure an **On New Message** source, follow these steps: 1. In the **Mule Palette** view, select **JMS > On New Message**. 2. Drag **On New Message** to the Studio canvas. 3. In the **On New Message** configuration screen, optionally change the value of the **Display Name** field. 4. Click the plus sign (**+**) next to the **Connector configuration** field to configure a global element that can be used by all instances of the source in the app. 5. In the **JMS Config** window, for **Connection**, select either one of the connection types to provide to this configuration: - **Active MQ Connection** - **Active MQ XA Connection** - **Generic Connection** - **Generic XA Connection** 6. On the **General** tab, specify the connection information for the connector, such as required libraries for the broker, JMS specification, cache strategy, authentication, and connection factory. 7. On the **TLS/SSL** tab, optionally specify a TLS configuration. 8. On the **Advanced** tab, optionally specify a reconnection strategy. If you selected one of the XA connection types, you can also configure the **XA connection pool** fields. 9. Click **OK** to close the window. 10. In the **On New Message** configuration screen, in **Destination**, specify the name of the destination from where to consume the message. 11. Configure other optional fields in the **On New Message** configuration screen. ## Add a Connector Operation to the Flow When you add a connector operation to your flow, you immediately define a specific operation for that connector to perform. To add an operation for JMS Connector, follow these steps: 1. In the **Mule Palette** view, select **JMS Connector** and then select the desired operation. 2. Drag the operation onto the Studio canvas and to the right of the input source. The following screenshot shows the JMS Connector operations in the Mule Palette view of Anypoint Studio: ![Select any of the JMS Connector Operations from the Mule Palette view on the right side of Anypoint Studio](/mulesoft/current/en-us/jms-connector/latest/_images/jms-operations.png) Figure 1. JMS Connector Operations ## Configure a Global Element for the Connector To avoid connectivity issues, create separate JMS configurations for publishing and consuming, instead of creating a shared JMS configuration for both publishing and consuming. JMS Connector comes with a fine-tuned set of default values for publishing and consuming messages. The only requirement is to configure which connection to use. You can define a global default behavior for all the operations associated with the configuration and then override each parameter in only the operations that require a custom behavior. To configure the global element for JMS Connector, follow these steps: 1. Select the operation in the Studio canvas. 2. In the configuration screen for the operation, click the plus sign (**+**) next to the **Connector configuration** field to access the global element configuration fields. 3. In the **JMS Config** window, for **Connection**, select either one of the connection types to provide to this configuration: - **Active MQ Connection** - **Active MQ XA Connection** - **Generic Connection** - **Generic XA Connection** 4. On the **General** tab, specify the connection information for the connector, such as required libraries for the broker, JMS specification, cache strategy, authentication, and connection factory. 5. On the **TLS/SSL** tab, optionally specify a TLS configuration. 6. On the **Advanced** tab, optionally specify a reconnection strategy. If you selected one of the XA connection types, you can also configure the **XA connection pool**. 7. On the **Consumer** tab, optionally define global default behavior configurations for all the **Consume** and **On New Message** operations you have in your flow. 8. On the **Producer** tab, optionally define global default behavior configurations for all the **Publish** and **Publish consume** operations you have in your flow. 9. Click **OK** to close the window. The following screenshot shows the JMS Connector **Global Element Configuration** window in Anypoint Studio: ![JMS Connector Global Element Configuration window](/mulesoft/current/en-us/jms-connector/latest/_images/jms-global-configuration.png) Figure 2. JMS Connector Global Element Configuration In the XML editor, the `` configuration looks like this: ```xml ``` In the following example, you define a default **Selector** behavior when consuming a message in any of the **Consume** or **On New Message** operations associated with this configuration, while every **Publish** or **Publish consume** operation produces the outgoing message with a **Time to live** (TTL) of 60 seconds: 1. In Studio, navigate to the **Global Elements** tab. 2. Click **Create**. 3. In the filter box type `jms` and select **JMS Config**. 4. Click **OK**. 5. In the **JMS Config** window, for **Connection**, select **Active MQ Connection**. 6. In the **Consumer** tab, set the **Selector** field to ``JMSType = `INVOICE`` to filter incoming messages as invoices. ![In the Consumer tab](/mulesoft/current/en-us/jms-connector/latest/_images/jms-global-configuration-consumer.png) Figure 3. JMS Connector Consumer Global Configuration 5. In the **Producer** tab, set the **Time to live** field to `60000` to define the default time the message is in the broker before it expires and is discarded. ![In the Producer tab](/mulesoft/current/en-us/jms-connector/latest/_images/jms-global-configuration-producer.png) Figure 4. JMS Connector Producer Global Configuration In the XML editor, the ``,`selector`, and `timeToLive` configurations looks like this: ```xml ``` You can override these properties at the operation level when required. In the following example, you publish a message with a shorter TTL. To override the value of the **Time to live** field set on the global element, follow these steps: 1. In Studio, select the **Publish** operation from your flow. 2. In the **Publish** configuration screen, scroll down to the **Publish Configuration** section. 3. Set the **Time to live** field to `10000` to override the default global configuration previously set. ![In the Publish Configuration section](/mulesoft/current/en-us/jms-connector/latest/_images/jms-publish-configuration-1.png) Figure 5. JMS Connector Publish Configuration Override In the XML editor, the `` and `timeToLive` configurations looks like this: ```xml ``` ## Configure the Connection to a Broker To configure the connection in the global element, define the connection by selecting **ActiveMQ Connection**, **ActiveMQ XA Connection**, **Generic Connection**, or **Generic XA Connection**, and set up the connection libraries and the JMS specification. JMS Connector also enables you to provide credentials, if you require an authenticated connection, and also to configure connection caching to increase the performance of the application. ### Configure an Active MQ Connection JMS Connector supports ActiveMQ 5 by using the **ActiveMQ Connection** setting. With this connection, you can use `JMS_1_1 (Default)` or `JMS_1_0_2b` specifications. You can also configure all the general connection parameters for JMS, as well as the custom parameters present only in ActiveMQ. After you declare the ActiveMQ connection, customize **Connection Factory** to your desired configuration. Every parameter in the connection comes with a default value, meaning that you are required to configure only the parameters relevant for your use case. Also, the ActiveMQ connection exposes parameters that are exclusive to the ActiveMQ implementation, like **Initial redelivery delay**. In the following example, you configure an **ActiveMQ Connection**: 1. In Studio, navigate to the **Global Elements** tab. 2. Click **Create**. 3. In the filter box type `jms` and select **JMS Config**. 4. Click **OK**. 5. In the **Connection** field select **ActiveMQ Connection**. 6. In the **Factory configuration** field, select **Edit Inline**. 7. Set the **Broker url** field value to the address of the broker to connect to, for example, `tcp://localhost:61616`. 8. Click **OK**. ![ActiveMQ Connection Configuration.](/mulesoft/current/en-us/jms-connector/latest/_images/jms-activemq-configuration.png) Figure 6. JMS Connector ActiveMQ Configuration In the XML editor, the `` and `` configuration looks like this: ```xml ``` ### Configure an Active MQ XA Connection Use **ActiveMQ XA Connection** to configure a connection that participates in Extended Architecture Transactions (XA transactions). This connection type requires Mule runtime 4.10.0 or later, and replaces enabling XA on the standard **ActiveMQ Connection**. In the following example, you configure an **ActiveMQ XA Connection**: 1. In Studio, navigate to the **Global Elements** tab. 2. Click **Create**. 3. In the filter box type `jms` and select **JMS Config**. 4. Click **OK**. 5. In the **Connection** field select **ActiveMQ XA Connection**. 6. In the **Factory configuration** field, select **Edit Inline**. 7. Set the **Broker url** field value to the address of the broker to connect to, for example, `tcp://localhost:61616`. 8. In the **Advanced** tab, optionally configure the **XA connection pool** fields for **Max pool size** and **Max idle seconds**. 9. Click **OK**. In the XML editor, the `` and `` configuration looks like this: ```xml ``` For a complete example of configuring XA transactions, see [Configuring XA Transactions in JMS Connector](https://docs.mulesoft.com/jms-connector/latest/jms-xa-transactions). ### Configure a Generic Connection Use **Generic Connection** to configure a connection to any broker implementation. JMS Connector provides a JNDI based (Java Naming and Directory Interface) connection factory builder that enables you to configure the connection using JNDI in the context of the application. In the following example, you configure **Generic Connection** to Artemis to use the `JMS_2_0` specification using JNDI: 1. In Studio, navigate to the **Global Elements** tab. 2. Click **Create**. 3. In the filter box, type `jms` and select **JMS Config**. 4. Click **OK**. 5. In the **Connection** field, select **Generic Connection**. 6. In the **Specification** field, select **JMS\_2\_0**. 7. In the **Connection factory** field, select **Edit inline**. 8. Set the **Connection factory jndi name** field to `ConnectionFactory`. 9. In the **Lookup destination** field, select any of the following options: - **NEVER** No lookup is done and the destinations are created using the existing JMS session. - **TRY\_ALWAYS** Tries to find the destination using JNDI, and in case it doesn’t exist, creates the destination using the current JMS session. - **ALWAYS** If a queue or topic cannot be found via JNDI, the lookup fails with a `JMS:DESTINATION_NOT_FOUND` error. 10. Select the **Name resolver builder** field. 11. Set the **Jndi initial context factory** field to `org.apache.activemq.artemis.ActiveMQInitialContextFactory`. 12. Set the **Jndi provider url** field to `tcp://localhost:61616?broker.persistent=false&broker.useJmx=false`. 13. Set **Provider properties** to **Edit inline**. 14. Click the plus sign (**+**) to add a new provider property. 15. In the **Provider property** window, set the **Key** field to `queue.jndi-queue-in` and the **Value** field to `in.queue`. 16. Click **Finish**. 17. Repeat Step 14. 18. Set the **Key** field to `topic.jndi-topic-in` and the **Value** field to `in.topic`. 19. Click **OK**. ![Generic Connection Configuration.](/mulesoft/current/en-us/jms-connector/latest/_images/jms-generic-configuration.png) Figure 7. JMS Connector Generic Configuration In the XML editor, the `` and `` configuration looks like this: ```xml ``` ### Configure a Generic XA Connection Use **Generic XA Connection** to configure a JNDI-based connection to any broker implementation that participates in Extended Architecture Transactions (XA transactions). This connection type requires Mule runtime 4.10.0 or later, and is configured the same way as **Generic Connection**, except that it uses a dedicated XA connection factory. In the following example, you configure a **Generic XA Connection** to Artemis using the `JMS_2_0` specification and JNDI: 1. In Studio, navigate to the **Global Elements** tab. 2. Click **Create**. 3. In the filter box, type `jms` and select **JMS Config**. 4. Click **OK**. 5. In the **Connection** field, select **Generic XA Connection**. 6. In the **Specification** field, select **JMS\_2\_0**. 7. In the **Connection factory** field, select **Edit inline**. 8. Set the **Connection factory jndi name** field to `ConnectionFactory`. 9. Configure the **Lookup destination** and **Name resolver builder** fields the same way as for **Generic Connection**. 10. In the **Advanced** tab, optionally configure the **XA connection pool** fields for **Max pool size** and **Max idle seconds**. 11. Click **OK**. In the XML editor, the `` and `` configuration looks like this: ```xml ``` ### Configure the Connection Libraries When you configure any connection type, you must always configure a library containing the JMS client implementation, because JMS Connector is not bound to any particular implementation. You can configure ActiveMQ external libraries and generic external libraries found in the global elements view of Studio, you can manually add the library dependency in your `pom.xml` file. #### ActiveMQ External Libraries For either ActiveMQ connection type (**ActiveMQ Connection** or **ActiveMQ XA Connection**), you can configure three libraries: - **ActiveMQ KahaDB** The `activemq-kahadb-store` dependency is required only when using an persistent in-memory broker based on the VM transport (such as `vm://localhost?broker.persistent=true`). This dependency provides a valid `org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter` implementation. In your `pom.xml` file in Studio, adding the dependency looks like this: ```xml org.apache.activemq activemq-kahadb-store 5.14.4 ``` - **ActiveMQ Broker** The `activemq-broker` dependency is required only when using an in-memory broker based on the VM transport (which is the one configured by default). This dependency provides a valid `org.apache.activemq.broker.Broker` implementation. In your `pom.xml` file in Studio, adding the dependency looks like this: ```xml org.apache.activemq activemq-broker 5.14.4 ``` - **ActiveMQ Client** The `activemq-client` dependency is always required. Choose one that provides a valid `org.apache.activemq.ActiveMQConnectionFactory` implementation. In your `pom.xml` file in Studio, adding the dependency looks like this: - ```xml org.apache.activemq activemq-client 5.14.4 ``` To configure these libraries in the Global Element view, follow these steps: 1. In Studio, navigate to the **Global Elements** tab. 2. Click **Create**. 3. In the filter box, type `jms` and select **JMS Config**. 4. Click **OK**. 5. In the **Connection** field, select **ActiveMQ Connection**. 6. In the **Required Libraries** section that shows the **ActiveMQ KahaDB**, **ActiveMQ Broker** and **ActiveMQ Client** libraries, click the **Configure…​** button to install the dependency. 7. Select any of the following install options: - **Add recommended library** Installs the recommended library. - **Use local file** Browse to a local file for the required engine library and install it. - **Add Maven dependency** Browse to the dependency and install it. #### Generic External Libraries For **Generic Connection** or **Generic XA Connection**, provide all the libraries that the connection factory of your implementation requires. Ensure that you supply all the required dependencies to the application. In the following example, you configure a generic library for a connection that uses a JMS 2.0 specification, which requires a generic connection with a different client library, like Apache Artemis: In your `pom.xml` file in Studio, adding the dependency looks like this: ```xml org.apache.activemq artemis-jms-client-all 2.17.0 ``` To configure these libraries in the Global Element view, follow these steps: 1. In Studio, navigate to the **Global Elements** tab. 2. Click **Create**. 3. In the filter box, type `jms` and select **JMS Config**. 4. Click **OK**. 5. In the **Connection** field, select **Generic Connection**. 6. In the **Required Libraries** section that shows the **JMS Client**, click the **Configure…​** button to install the dependency. 7. Select any of the following install options: - **Add recommended library** Installs the recommended library. - **Use local file** Browse to a local file for the required engine library and install it. - **Add Maven dependency** Browse to the dependency and install it. ### Configure the JMS Specification The JMS **Specification** you configure must be supported by the broker implementation associated with the connection; otherwise, the connection fails. Note that features that are available only in `JMS_2_0` won’t work with any other specification. To configure the JMS specification in Studio, follow these steps: 1. In Studio, open the **JMS Config** global element window. 2. In the **Specification** field, select one of the following supported specifications: - **JMS\_1\_1 (Default)** - **JMS\_1\_0\_2b** - **JMS\_2\_0** 3. Click **OK**. ![In the Specification field select one of the supported specifications](/mulesoft/current/en-us/jms-connector/latest/_images/jms-spec-config.png) Figure 8. JMS Connector specification configuration In the XML editor, the `specification` configuration looks like this: ```xml ``` ### Configure Connection Caching To connect with a broker and execute required operations, JMS Connector creates multiple sessions of consumers and producers that can be cached and reused to increase application performance. JMS Connector enables you to configure the **Caching strategy** field to use when creating new connections. By default, both consumers and producers are cached and as many concurrent instances are cached in memory. Do not disable the sessions cache by using the **No caching** configuration, which is used only with a custom connection factory that already manages its own cache. In the following example you configure the caching strategy: 1. In Studio, open the **JMS Config** global element window. 2. In the **Caching strategy** field, select **Default caching (Default)**. 3. Set the **Session cache size** field to `100`. 4. Select **Cache producers**. 5. Click **OK**. ![In the Caching strategy field select the desired caching strategy](/mulesoft/current/en-us/jms-connector/latest/_images/jms-caching-config.png) Figure 9. JMS Connector caching strategy configuration In the XML editor, the `` and `` configuration looks like this: ```xml ``` In the following XML example, the `` configuration looks like this: ```xml ``` ### Configure the Client Identifier and Credentials for Authentication The client identifier associates a connection and its objects with a state that is maintained on behalf of the client by a provider. It is mandatory for identifying an unshared durable subscription. Note that the client state identified in the **Client id** can be used by only one connection at a time. In the following example, you configure an authenticated connection and the client identifier: 1. In Studio, open the **JMS Config** global element window. 2. In the **Connection** section, set the **Username** field to `${env.user}` and the **Password** field to `${env.pass}`. 3. Set the **Client id** field to `${env.clientId}`. 4. Click **OK**. ![In the Connection section, set the Username, Password, and Client id fields.](/mulesoft/current/en-us/jms-connector/latest/_images/jms-authentication-config.png) Figure 10. JMS Connector authenticated connection and client identifier configuration In the XML editor, the `username`, `password`, and `clientId` configuration looks like this: ```xml ``` ## View the App Log To check for problems, you can view the app log as follows: - If you’re running the app from Anypoint Platform, the output is visible in the Anypoint Studio console window. - If you’re running the app using Mule from the command line, the app log is visible in your OS console. Unless the log file path is customized in the app’s log file (`log4j2.xml`), you can also view the app log in the default location `MULE_HOME/logs/.log`. ## See Also - [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors) - [Using Anypoint Studio to Configure a Connector](https://docs.mulesoft.com/connectors/introduction/intro-config-use-studio) - [Configuring XA Transactions in JMS Connector](https://docs.mulesoft.com/jms-connector/latest/jms-xa-transactions) - [Upgrading and Migrating JMS Connector](https://docs.mulesoft.com/jms-connector/latest/jms-connector-upgrade-migrate) - [JMS Connector Reference](https://docs.mulesoft.com/jms-connector/latest/jms-connector-reference) - [Salesforce Help](https://help.salesforce.com) --- product: JMS Connector version: 1.2 keywords: jms, connector, consume, source, listener, topic, subscription --- # Using Topic Subscriptions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Topics in JMS allow you to configure how the subscription behaves regarding the connection of the consumer and also how this consumers interact between each other. Using Mule’s JMS Connector you can handle of the aspects of a Topic subscription using the 'topic-consumer' configuration in both the `consumer` and `listener` operations. ## Registering Durable Subscriptions Durable subscriptions allows you to receive messages that were published to the topic while the consumer was offline. Once a durable subscription registered, each time a consumer is available it will receive all the messages published before the connection was established: ```xml ``` Then the JMS provider stores the messages sent or published to the topic, as it would store messages sent to a queue. If this or another application creates a 'topic-consumer' using the same connection and its client ID, the same topic, and the same subscription name, the subscription is reactivated, and the JMS provider delivers the messages that were published while the subscriber was inactive. ## Allowing Multiple Consumers on the Same Subscription In JMS 1.1, a subscription on a topic was not permitted to have more than one consumer at a time, meaning that the work of processing messages on a topic subscription could not be shared, thereby limiting the scalability of the application. This restriction has been removed in JMS 2.0 by the introduction of **shared subscriptions**. The JMS Connector, **when configured with a JMS 2.0 connection**, allows you to declare any 'topic-consumer' as part of a `shared` subscription: ```xml ``` With this configuration on two different `listener` instances, when a Message is published to the invoices destination it will be delivered only to one of the listeners and not the other. ## How to Ignore Self Published Messages There are cases in which you may not want to receive the Messages that were published to a Topic by the same application. For this cases, you can use the `noLocal` parameter in the 'topic-consumer', thus preventing the Consumer to receive Messages published to the Topic **by the same Connection**: ```xml ``` Consumers configured as `noLocal` **can’t** be part of a `shared` subscription. ## See Also - [To Listen For New Messages](https://docs.mulesoft.com/jms-connector/1.2/jms-listener) - [To Consume Messages](https://docs.mulesoft.com/jms-connector/1.2/jms-consume)