Camel Component: JMS - 6.3

Talend ESB Mediation Developer Guide

EnrichVersion
6.3
EnrichProdName
Talend Data Fabric
Talend Data Services Platform
Talend ESB
Talend MDM Platform
Talend Open Studio for ESB
Talend Real-Time Big Data Platform
task
Design and Development
EnrichPlatform
Talend ESB

Important

If you are using Apache ActiveMQ, you should prefer the Camel Component: ActiveMQ component as it has been optimized for it. All of the options and samples on this page are also valid for the ActiveMQ component.

The JMS component allows messages to be sent to (or consumed from) a JMS Queue or Topic. The implementation of the JMS Component uses Spring's JMS support for declarative transactions, using Spring's JmsTemplate for sending and a MessageListenerContainer for consuming.

Maven users will need to add the following dependency to their pom.xml for this component:

<dependency>
   <groupId>org.apache.camel</groupId>
   <artifactId>camel-jms</artifactId>
   <!-- use the same version as your Camel core version -->
   <version>x.x.x</version>
</dependency>

URI format

jms:[queue:|topic:]destinationName[?options]

where destinationName is a JMS queue or topic name. By default, the destinationName is interpreted as a queue name. For example, to connect to the queue, FOO.BAR, use:

jms:FOO.BAR

You can include the optional queue: prefix, if you prefer:

jms:queue:FOO.BAR

To connect to a topic, you must include the topic: prefix. For example, to connect to the topic, Stocks.Prices, use:

jms:topic:Stocks.Prices

Append query options to the URI using the following format, ?option=value&option=value&...

Notes

Important

If you are using ActiveMQ, note that the JMS component reuses Spring 2's JmsTemplate for sending messages. This is not ideal for use in a non-J2EE container and typically requires some caching in the JMS provider to avoid poor performance .

If you intend to use Apache ActiveMQ as your Message Broker, then we recommend that you either:

  • Use the Camel Component: ActiveMQ component, which is already configured to use ActiveMQ efficiently, or

  • Use the PoolingConnectionFactory in ActiveMQ.

If you are consuming messages and using transactions (transacted=true) then the default settings for cache level can impact performance. If you are using XA transactions then you cannot cache as it can cause the XA transaction not to work properly. If you are not using XA, then you should consider caching as it speeds up performance, such as setting cacheLevelName=CACHE_CONSUMER.

The default setting for cacheLevelName is CACHE_AUTO. This default auto detects the mode and sets the cache level accordingly to:

  • CACHE_CONSUMER = if transacted = false

  • CACHE_NONE = if transacted = true

So you can say the default setting is conservative. Consider using cacheLevelName=CACHE_CONSUMER if you are using non-XA transactions.

If you wish to use durable topic subscriptions, you need to specify both clientId and durableSubscriptionName. The value of the clientId must be unique and can only be used by a single JMS connection instance in your entire network. You may prefer to use Virtual Topics instead to avoid this limitation. More background on durable messaging is available on the ActiveMQ site.

When using message headers, the JMS specification states that header names must be valid Java identifiers. So try to name your headers to be valid Java identifiers. One benefit of doing this is that you can then use your headers inside a JMS Selector (whose SQL92 syntax mandates Java identifier syntax for headers).

A simple strategy for mapping header names is used by default. The strategy is to replace any dots in the header name with the underscore character and to reverse the replacement when the header name is restored from a JMS message sent over the wire. What does this mean? No more losing method names to invoke on a bean component, no more losing the filename header for the File Component, and so on.

The current header name strategy for accepting header names in Camel is as follows:

  • Dots are replaced by _DOT_ and the replacement is reversed when Camel consumes the message. (for example, org.apache.camel.MethodName becomes org_DOT_apache_DOT_camel_DOT_MethodName).

  • Hyphen is replaced by _HYPHEN_ and the replacement is reversed when Camel consumes the message.

Warning

Are you using transactions? If you are consuming messages, and have transacted=true, then the default settings for cache level can impact performance. The default setting is always CACHE_CONSUMER. However, with the CACHE_AUTO setting, when you use transactions the cache level is effectively set to CACHE_NONE, appropriate for transactions.

Options

You can configure many different properties on the JMS endpoint which map to properties on the JMSConfiguration POJO. Note: Many of these properties map to properties on Spring JMS, which Camel uses for sending and receiving messages. You can get more information about these properties by consulting the relevant Spring documentation.

The options is divided into two tables, the first one with the most common options used. The latter contains the rest.

Most commonly used options

Option

Default Value

Description

clientId

null

Sets the JMS client ID to use. Note that this value, if specified, must be unique and can only be used by a single JMS connection instance. It is typically only required for durable topic subscriptions. You may prefer to use Virtual Topics instead.

concurrentConsumers

1

Specifies the default number of concurrent consumers. Starting with Camel 2.11, this option can also be used when doing request/reply over JMS. See also the maxMessagesPerTask option to control dynamic scaling up/down of threads.

disableReplyTo

false

If true, a producer will behave like a InOnly exchange with the exception that JMSReplyTo header is sent out and not be suppressed like in the case of InOnly. Like InOnly the producer will not wait for a reply. A consumer with this flag will behave like InOnly. This feature can be used to bridge InOut requests to another queue so that a route on the other queue will send its response directly back to the original JMSReplyTo.

durableSubscriptionName

null

The durable subscriber name for specifying durable topic subscriptions. The clientId option must be configured as well.

maxConcurrentConsumers

1

Specifies the maximum number of concurrent consumers. Starting with Camel 2.11, this option can also be used when doing request/reply over JMS. See also the maxMessagesPerTask option to control dynamic scaling up/down of threads.

maxMessagesPerTask

-1

The number of messages per task, -1 for unlimited. If you use a range for concurrent consumers (e.g. min < max), then this option can be used to set a value to e.g. 100 to control how fast the consumers will shrink when less work is required.

preserveMessageQos

false

Set to true, if you want to send message using the QoS settings specified on the message, instead of the QoS settings on the JMS endpoint. The following three headers are considered JMSPriority, JMSDeliveryMode, and JMSExpiration. You can provide all or only some of them. If not provided, Camel will fall back to use the values from the endpoint instead. So, when using this option, the headers override the values from the endpoint. The explicitQosEnabled option, by contrast, will only use options set on the endpoint, and not values from the message header.

replyTo

null

Provides an explicit ReplyTo destination, which overrides any incoming value of Message.getJMSReplyTo(). If you do [Request Reply] over JMS then read the Camel Request-reply over JMS section for more details.

replyToType

null

Allows to explicit specify which kind of strategy to use for replyTo queues when doing request/reply over JMS. Possible values are: {{Temporary}}, {{Shared}}, or {{Exclusive}}. By default Camel will use temporary queues. However if {{replyTo}} has been configured, then {{Shared}} is used by default. This option allows you to use exclusive instead of shared queues. Check the Camel website for more about this option.

requestTimeout

20000

Producer only: The timeout for waiting for a reply when using the InOut Exchange Pattern (in milliseconds). The default is 20 seconds. From Camel 2.13/2.12.3 onwards you can include the header "CamelJmsRequestTimeout" to override this endpoint configured timeout value, and thus have per message individual timeout values. See below in section About time to live for more details. See also the requestTimeoutCheckerInterval option.

selector

null

Sets the JMS Selector, which is an SQL 92 predicate that is used to filter messages within the broker. You may have to encode special characters such as = as %3D.

timeToLive

null

When sending messages, specifies the time-to-live of the message (in milliseconds).

transacted

false

Specifies whether to use transacted mode for sending/receiving messages using the InOnly Exchange Pattern.

testConnectionOnStartup

false

Specifies whether to test the connection on startup. This ensures that when Camel starts that all JMS consumers and producers have a valid connection to the JMS broker. If a connection cannot be granted then Camel throws an exception on startup. This ensures that Camel is not started with failed connections.

All the other options

Option

Default Value

Description

acceptMessagesWhile-Stopping

false

Specifies whether the consumer accept messages while it is stopping. You may consider enabling this option, if you start and stop JMS routes at runtime, while there are still messages enqued on the queue. If this option is false, and you stop the JMS route, then messages may be rejected, and the JMS broker would have to attempt redeliveries, which yet again may be rejected, and eventually the message may be moved at a dead letter queue on the JMS broker. To avoid this its recommended to enable this option.

acknowledgementModeName

AUTO_ ACKNOWLEDGE

The JMS acknowledgement name, which is one of: SESSION_TRANSACTED, CLIENT_ACKNOWLEDGE, AUTO_ACKNOWLEDGE, DUPS_OK_ACKNOWLEDGE

acknowledgementMode

-1

The JMS acknowledgement mode defined as an Integer. Allows you to set vendor-specific extensions to the acknowledgment mode. For the regular modes, it is preferable to use the acknowledgementModeName instead.

allowNullBody

true

Whether to allow sending messages with no body. If this option is false and the message body is null, then an JMSException is thrown.

alwaysCopyMessage

false

If true, Camel will always make a JMS message copy of the message when it is passed to the producer for sending. Copying the message is needed in some situations, such as when a replyToDestinationSelectorName is set (incidentally, Camel will set the alwaysCopyMessage option to true, if a replyToDestinationSelectorName is set)

asyncStartListener

false

Whether to startup the JmsConsumer message listener asynchronously, when starting a route. For example if a JmsConsumer cannot get a connection to a remote JMS broker, then it may block while retrying and/or failover. This will cause Camel to block while starting routes. By setting this option to true, you will let routes startup, while the JmsConsumer connects to the JMS broker using a dedicated thread in asynchronous mode. If this option is used, then beware that if the connection could not be established, then an exception is logged at WARN level, and the consumer will not be able to receive messages; You can then restart the route to retry.

asyncStopListener

false

Whether to stop the JmsConsumer message listener asynchronously, when stopping a route.

autoStartup

true

Specifies whether the consumer container should auto-startup.

asyncConsumer

false

Whether the JmsConsumer processes the Exchange asynchronously using the Asynchronous Routing Engine. If enabled then the JmsConsumer may pick up the next message from the JMS queue, while the previous message is being processed asynchronously. This means that messages may be processed not 100% strictly in order. If disabled (as default) then the Exchange is fully processed before the JmsConsumer will pickup the next message from the JMS queue. Note if transactions have been enabled, then asyncConsumer=true does not run asynchronously, as transactions must be executed synchronously.

cacheLevelName

CACHE_CONSUMER

Sets the cache level by name for the underlying JMS resources. Possible values are: CACHE_AUTO, CACHE_CONNECTION, CACHE_CONSUMER, CACHE_NONE, and CACHE_SESSION. See the Spring documentation and see the warning above.

cacheLevel

null

Sets the cache level by ID for the underlying JMS resources. See cacheLevelName for more details.

consumerType

Default

The consumer type to use, which can be one of: Simple, Default or Custom. The consumer type determines which Spring JMS listener to use.

  • Default will use org.springframework. jms.listener. DefaultMessage ListenerContainer
  • Simple will use org.springframework. jms.listener. SimpleMessage ListenerContainer
  • When Custom is specified, the MessageListenerContainerFactory defined by the messageListener-ContainerFactoryRef option will determine what AbstractMessage-ListenerContainer to use.

connectionFactory

null

The default JMS connection factory to use for the listenerConnectionFactory and templateConnectionFactory, if neither is specified.

defaultTaskExecutorType

Specifies what default TaskExecutor type to use in the DefaultMessageListenerContainer, for both consumer endpoints and the ReplyTo consumer of producer endpoints. Possible values: SimpleAsync (uses Spring's SimpleAsyncTaskExecutor) or ThreadPool (uses Spring's ThreadPoolTaskExecutor with optimal values - cached threadpool-like). If not set, it defaults to a cached thread pool for consumer endpoints and SimpleAsync for reply consumers. The use of ThreadPool is recommended to reduce "thread trash" in elastic configurations with dynamically increasing and decreasing concurrent consumers.

deliveryMode

null

Camel 2.12.2/2.13: Specifies the delivery mode to be used. Possibles values are those defined by javax.jms.DeliveryMode.

deliveryPersistent

true

Specifies whether persistent delivery is used by default.

destination

null

Specifies the JMS Destination object to use on this endpoint.

destinationName

null

Specifies the JMS destination name to use on this endpoint.

destinationResolver

null

A pluggable org.springframework.jms.support. destination.DestinationResolver that allows you to use your own resolver (for example, to lookup the real destination in a JNDI registry).

disableTimeToLive

false

Use this option to force disabling time to live. For example when you do request/reply over JMS, then Camel will by default use the {{requestTimeout}} value as time to live on the message being sent. The problem is that the sender and receiver systems have to have their clocks synchronized, so they are in sync. This is not always so easy to archive. So you can use {{disableTimeToLive=true}} to *not* set a time to live value on the send message. Then the message will not expire on the receiver system.

eagerLoadingOfProperties

false

Enables eager loading of JMS properties as soon as a message is received, which is generally inefficient, because the JMS properties might not be required. However, this feature can sometimes catch any issues with the underlying JMS provider and the use of JMS properties at an early stage. This feature can also be used for testing purposes, to ensure JMS properties can be understood and handled correctly.

exceptionListener

null

Specifies the JMS Exception Listener that is to be notified of any underlying JMS exceptions.

errorHandler

null

Specifies a org.springframework.util.ErrorHandler to be invoked in case of any uncaught exceptions thrown while processing a message. By default these exceptions will be logged at the WARN level, if no errorHandler has been configured. You can configure logging level and whether stack traces should be logged using the below two options. This makes it much easier to configure, than having to code a custom errorHandler.

errorHandlerLoggingLevel

WARN

Allows for configuring the default errorHandler logging level for logging uncaught exceptions.

errorHandlerLogStack-Trace

true

Allows to control whether stacktraces should be logged or not, by the default errorHandler.

explicitQosEnabled

false

Set if the deliveryMode, priority or timeToLive qualities of service should be used when sending messages. This option is based on Spring's JmsTemplate. The deliveryMode, priority and timeToLive options are applied to the current endpoint. This contrasts with the preserveMessageQos option, which operates at message granularity, reading QoS properties exclusively from the Camel In message headers.

exposeListenerSession

true

Specifies whether the listener session should be exposed when consuming messages.

forceSendOriginalMessage

false

When using mapJmsMessage=false Camel will create a new JMS message to send to a new JMS destination if you touch the headers (get or set) during the route. Set this option to true to force Camel to send the original JMS message that was received.

idleConsumerLimit

1

Specify the limit for the number of consumers that are allowed to be idle at any given time.

idleTaskExecutionLimit

1

Specifies the limit for idle executions of a receive task, not having received any message within its execution. If this limit is reached, the task will shut down and leave receiving to other executing tasks (in the case of dynamic scheduling; see the maxConcurrentConsumers setting). There is additional doc available from Spring.

idleConsumerLimit

1

Specify the limit for the number of consumers that are allowed to be idle at any given time.

includeSentJMSMessageID

false

Only applicable when sending to JMS destination using InOnly (eg fire and forget). Enabling this option will enrich the Camel Exchange with the actual JMSMessageID that was used by the JMS client when the message was sent to the JMS destination.

includeAllJMSXProperties

false

Camel 2.11.2/2.12: Whether to include all JMSXxxx properties when mapping from JMS to Camel Message. Setting this to true will include properties such as JMSXAppID, and JMSXUserID etc. Note: If you are using a custom headerFilterStrategy then this option does not apply.

jmsMessageType

null

Allows you to force the use of a specific javax.jms.Message implementation for sending JMS messages. Possible values are: Bytes, Map, Object, Stream, Text. By default, Camel would determine which JMS message type to use from the In body type. This option allows you to specify it.

jmsKeyFormatStrategy

default

Pluggable strategy for encoding and decoding JMS keys so they can be compliant with the JMS specification. Camel provides two implementations out of the box: default and passthrough. The default strategy will safely marshal dots ('.') and hyphens ('-') The passthrough strategy leaves the key as is. Can be used for JMS brokers which do not care whether JMS header keys contain illegal characters. You can provide your own implementation of the org.apache.camel.component.jms. JmsKeyFormatStrategy and refer to it using the # notation.

jmsOperations

null

Allows you to use your own implementation of the org.springframework.jms.core. JmsOperations interface. Camel uses JmsTemplate as default. Can be used for testing purpose (rarely used, as stated in the Spring API docs) .

lazyCreateTransaction-Manager

true

If true, Camel will create a JmsTransactionManager, if there is no transactionManager injected when option transacted=true.

listenerConnection-Factory

null

The JMS connection factory used for consuming messages.

mapJmsMessage

true

Specifies whether Camel should auto map the received JMS message to an appropiate payload type, such as javax.jms.TextMessage to a String etc. See section about how mapping works below for more details.

maximumBrowseSize

-1

Limits the number of messages fetched at most, when browsing endpoints using Browse or JMX API.

messageConverter

null

To use a custom Spring org.springframework.jms.support. converter.MessageConverter so you can be totally in control how to map to and from a javax.jms.Message.

messageIdEnabled

true

When sending, specifies whether message IDs should be added.

messageListener-ContainerFactoryRef

null

Registry ID of the MessageListenerContainerFactory used to determine what AbstractMessageListenerContainer to use to consume messages. Setting this will automatically set consumerType to Custom.

messageTimestampEnabled

true

Specifies whether timestamps should be enabled by default on sending messages.

password

null

The password for the connector factory.

priority

4

Values greater than 1 specify the message priority when sending (where 0 is the lowest priority and 9 is the highest). The explicitQosEnabled option must also be enabled in order for this option to have any effect.

pubSubNoLocal

false

Specifies whether to inhibit the delivery of messages published by its own connection.

receiveTimeout

None

The timeout for receiving messages (in milliseconds).

recoveryInterval

5000

Specifies the interval between recovery attempts, that is, when a connection is being refreshed, in milliseconds. The default is 5000 ms, that is, 5 seconds.

replyToCacheLevelName

CACHE_CONSUMER

Sets the cache level by name for the reply consumer when doing request/reply over JMS. This option only applies when using fixed reply queues (not temporary). Camel will by default use: CACHE_CONSUMER for exclusive or shared w/ {{replyToSelectorName}}. And CACHE_SESSION for shared without replyToSelectorName. Some JMS brokers such as IBM WebSphere may require to set the replyToCacheLevelName=CACHE_NONE to work. Note: If using temporary queues then CACHE_NONE is not allowed, and you must use a higher value such as CACHE_CONSUMER or CACHE_SESSION.

replyToDestination-SelectorName

null

Sets the JMS Selector using the fixed name to be used so you can filter out your own replies from the others when using a shared queue (that is, if you are not using a temporary reply queue).

replyToDelivery-Persistent

true

Specifies whether to use persistent delivery by default for replies.

requestTimeout-CheckerInterval

1000

Configures how often Camel should check for timed out Exchanges when doing request/reply over JMS. By default Camel checks once per second. But if you must react faster when a timeout occurs, then you can lower this interval, to check more frequently. The timeout is determined by the requestTimeout option.

subscriptionDurable

false

@deprecated: Enabled by default, if you specify a durableSubscriptionName and a clientId.

taskExecutor

null

Allows you to specify a custom task executor for consuming messages.

taskExecutorSpring2

null

To use when using Spring 2.x with Camel. Allows you to specify a custom task executor for consuming messages.

templateConnection-Factory

null

The JMS connection factory used for sending messages.

transactedInOut

false

@deprecated: Specifies whether to use transacted mode for sending messages using the InOut Exchange Pattern. Applies only to producer endpoints. See Enabling Transacted Consumption on the Camel website for more details.

transactionManager

null

The Spring transaction manager to use.

transactionName

JmsConsumer [destination-Name]

The name of the transaction to use.

transactionTimeout

null

The timeout value of the transaction, if using transacted mode.

transferException

false

If enabled and you are using Request Reply messaging (InOut) and an Exchange failed on the consumer side, then the caused Exception will be send back in response as a javax.jms.ObjectMessage. If the client is Camel, the returned Exception is rethrown. This allows you to use Camel Camel Component: JMS as a bridge in your routing; for example, using persistent queues to enable robust routing. Notice that if you also have transferExchange enabled, this option takes precedence. The caught exception is required to be serializable. The original Exception on the consumer side can be wrapped in an outer exception such as org.apache.camel. RuntimeCamelException when returned to the producer.

transferExchange

false

You can transfer the exchange over the wire instead of just the body and headers. The following fields are transferred: In body, Out body, Fault body, In headers, Out headers, Fault headers, exchange properties, exchange exception. This requires that the objects are serializable. Camel will exclude any non-serializable objects and log it at WARN level. You *must* enable this option on both the producer and consumer side, so Camel knows the payloads form an Exchange and not a regular payload.

username

null

The username for the connector factory.

useMessageIDAs-CorrelationID

false

Specifies whether JMSMessageID should always be used as JMSCorrelationID for InOut messages.

Message Mapping between JMS and CamelCamel automatically maps messages between javax.jms.Message and org.apache.camel.Message. When sending a JMS message, Camel converts the message body to the following JMS message types:

Body Type

JMS Message

Comment

String

javax.jms.TextMessage

 

org.w3c.dom.Node

javax.jms.TextMessage

The DOM will be converted to String.

Map

javax.jms.MapMessage

 

java.io.Serializable

javax.jms.ObjectMessage

 

byte[]

javax.jms.BytesMessage

 

java.io.File

javax.jms.BytesMessage

 

java.io.Reader

javax.jms.BytesMessage

 

java.io.InputStream

javax.jms.BytesMessage

 

java.nio.ByteBuffer

javax.jms.BytesMessage

 

When receiving a JMS message, Camel converts the JMS message to the following body type:

JMS Message

Body Type

javax.jms.TextMessage

String

javax.jms.BytesMessage

byte[]

javax.jms.MapMessage

Map<String, Object>

javax.jms.ObjectMessage

Object

Message format when sending

The exchange that is sent over the JMS wire must conform to the JMS Message spec.

For the exchange.in.header the following rules apply for the header keys :

  • Keys starting with JMS or JMSX are reserved.

  • exchange.in.headers keys must be literals and all be valid Java identifiers (do not use dots in the key name).

  • Camel replaces dots and hyphens and the reverse when when consuming JMS messages:

    . is replaced by _DOT_ and the reverse replacement when Camel consumes the message.

    - is replaced by _HYPHEN_ and the reverse replacement when Camel consumes the message.

  • See also the option jmsKeyFormatStrategy, which allows you to use your own custom strategy for formatting keys.

For the exchange.in.header, the following rules apply for the header values :

  • The values must be primitives or their counter objects (such as Integer, Long, Character). The types, String, CharSequence, Date, BigDecimal and BigInteger are all converted to their toString() representation. All other types are dropped.

Camel will log with category org.apache.camel.component.jms.JmsBinding at DEBUG level if it drops a given header value. For example:

2008-07-09 06:43:04,046 [main           ] DEBUG JmsBinding  
- Ignoring non primitive header: order of class: org.apache.camel.component
.jms.issues.DummyOrder with value: DummyOrder{orderId=333, itemId=4444, 
quantity=2}

Message format when receiving

Camel adds the following properties to the Exchange when it receives a message:

Property

Type

Description

org.apache.camel.jms. replyDestination

javax.jms.Destination

The reply destination.

Camel adds the following JMS properties to the In message headers when it receives a JMS message:

Header

Type

Description

JMSCorrelationID

String

The JMS correlation ID.

JMSDeliveryMode

int

The JMS delivery mode.

JMSDestination

javax.jms.Destination

The JMS destination.

JMSExpiration

long

The JMS expiration.

JMSMessageID

String

The JMS unique message ID.

JMSPriority

int

The JMS priority (with 0 as the lowest priority and 9 as the highest).

JMSRedelivered

boolean

the JMS message redelivered.

JMSReplyTo

javax.jms.Destination

The JMS reply-to destination.

JMSTimestamp

long

The JMS timestamp.

JMSType

String

The JMS type.

JMSXGroupID

String

The JMS group ID.

As all the above information is standard JMS you can check the JMS documentation for further details.

About using Camel to send and receive messages and JMSReplyTo

The JMS component is complex and you have to pay close attention to how it works in some cases. So this is a short summary of some of the areas/pitfalls to look for.

When Camel sends a message using its JMSProducer, it checks the following conditions:

  • The message exchange pattern,

  • Whether a JMSReplyTo was set in the endpoint or in the message headers,

  • Whether any of the following options have been set on the JMS endpoint: disableReplyTo, preserveMessageQos, explicitQosEnabled.

All this can be complex to understand and configure to support your use case.

JmsProducer

The JmsProducer behaves as follows, depending on configuration:

Exchange Pattern

Other options

Description

InOut

-

Camel will expect a reply, set a temporary JMSReplyTo, and after sending the message, it will start to listen for the reply message on the temporary queue.

InOut

JMSReplyTo is set

Camel will expect a reply and, after sending the message, it will start to listen for the reply message on the specified JMSReplyTo queue.

InOnly

-

Camel will send the message and not expect a reply.

InOnly

JMSReplyTo is set

By default, Camel discards the JMSReplyTo destination and clears the JMSReplyTo header before sending the message. Camel then sends the message and does not expect a reply. Camel logs this in the log at DEBUG level. You can use preserveMessageQuo=true to instruct Camel to keep the JMSReplyTo. In all situations the JmsProducer does not expect any reply and thus continue after sending the message.

JmsConsumer

The JmsConsumer behaves as follows, depending on configuration:

Exchange Pattern

Other options

Description

InOut

-

Camel will send the reply back to the JMSReplyTo queue.

InOnly

-

Camel will not send a reply back, as the pattern is InOnly.

-

disableReplyTo=true

This option suppresses replies.

Thus, pay attention to the message exchange pattern set on your exchanges.

If you send a message to a JMS destination in the middle of your route you can specify the exchange pattern to use, see more at Request Reply. This is useful if you want to send an InOnly message to a JMS topic:

from("activemq:queue:in")
   .to("bean:validateOrder")
   .to(ExchangePattern.InOnly, "activemq:topic:order")
   .to("bean:handleOrder");

Configuring different JMS providers

You can configure your JMS provider in Spring XML as follows:

<camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
   <jmxAgent id="agent" disabled="true"/>
</camelContext>

<bean id="activemq" 
   class="org.apache.activemq.camel.component.ActiveMQComponent">
   <property name="connectionFactory">
      <bean class="org.apache.activemq.ActiveMQConnectionFactory">
         <property name="brokerURL" value=
            "vm://localhost?broker.persistent=false&broker.useJmx=false"/>
      </bean>
   </property>
</bean>

Basically, you can configure as many JMS component instances as you wish and give them a unique name using the id attribute . The preceding example configures an activemq component. You could do the same to configure MQSeries, TibCo, BEA, Sonic and so on.

Once you have a named JMS component, you can then refer to endpoints within that component using URIs. For example for the component name, activemq, you can then refer to destinations using the URI format, activemq:[queue:|topic:]destinationName. You can use the same approach for all other JMS providers.

This works by the SpringCamelContext lazily fetching components from the Spring context for the scheme name you use for Endpoint URIs and having the Component resolve the endpoint URIs.

Samples

JMS is used in many examples for other components as well. But we provide a few samples below to get started.

Receiving from JMS

In the following sample we configure a route that receives JMS messages and routes the message to a POJO:

from("jms:queue:foo").to("bean:myBusinessLogic");

You can of course use any of the EIP patterns so the route can be context based. For example, here's how to filter an order topic for the big spenders:

from("jms:topic:OrdersTopic")
   .filter().method("myBean", "isGoldCustomer")
   .to("jms:queue:BigSpendersQueue");

Sending to a JMS

In the sample below we poll a file folder and send the file content to a JMS topic. As we want the content of the file as a TextMessage instead of a BytesMessage, we need to convert the body to a String :

from("file://orders")
   .convertBodyTo(String.class).
   .to("jms:topic:OrdersTopic");

Using Annotations

Camel also has annotations so you can use POJO Consuming and POJO Producing.

Spring DSL sample

The preceding examples use the Java DSL. Camel also supports Spring XML DSL. Here is the big spender sample using Spring DSL:

<route>
   <from uri="jms:topic:OrdersTopic"/>
   <filter>
      <method bean="myBean" method="isGoldCustomer"/>
      <to uri="jms:queue:BigSpendersQueue"/>
   </filter>
</route>

Other samples

JMS appears in many of the examples for other components and EIP patterns, as well in the online Apache Camel documentation. A recommended tutorial is this one that uses JMS but focuses on how well Spring Remoting and Camel work together Tutorial-JmsRemoting.