<jms:listener config-ref="config" destination="#[vars.destination]"/>
To Listen For New Messages
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:
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.
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:
<flow name="consumer">
<jms:listener config-ref="JMS_config" destination="openTickets" selector="JMSPriority=8"/>
</flow>
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:
<jms:listener config-ref="config" destination="#[vars.destination]">
<jms:response priority="8" persistentDelivery="true">
<jms:body>#['Message received was: ' ++ payload]</jms:body>
<jms:properties>#[{'processedAt': now}]</jms:properties>
</jms:response>
</jms:listener>
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:
<jms:listener config-ref="config" destination="#[vars.destination]">
<jms:response priority="8" persistentDelivery="true">
<jms:response ignoreReplyTo="true" />
</jms:response>
</jms:listener>
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:
<jms:listener config-ref="JMS_config" destination="#[vars.destination]">
<jms:consumer-type>
<jms:topic-consumer/>
</jms:consumer-type>
</jms:listener>
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.