JMS Component
The JMS component allows messages to be sent to a JMS![]()
Queue or Topic; or messages to be 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.
URI format
jms:[topic:]destinationName?properties
So for example to send to queue FOO.BAR you would use
You can be completely specific if you wish via
If you want to send to a topic called Stocks.Prices then you would use
Using Temporary Destinations
As of 1.4.0 of Camel you can use temporary queues using the following URL format
or temporary topics as
Where foo and bar, the text after the String jms:temp:queue: or jms:temp:topic:, are the names of the destinations. This enables multiple routes or processors or beans to refer to the same temporary destination. e.g. you can create 3 temporary destinations and use them in routes as inputs or outputs by referring to them by name.
Notes
If you wish to use durable topic subscriptions, you need to specify both clientId and durableSubscriberName. Note that 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 here![]()
.
When using message headers; the JMS specification states that header names must be valid Java identifiers. So by default camel will ignore any headers which do not match this rule. So try name your headers as if they are valid Java identifiers. One added bonus of this is that you can then use your headers inside a JMS Selector - which uses SQL92 syntax which mandates Java identifier syntax for headers.
From Camel 1.4 a simple strategy for mapping headers names is used by default. The strategy is to replace any dots in the headername with underscore, and vice-versa when the header name is restored from the JMS message that was sent over the wire. What does this means? No more loosing method names to invoke on a bean component, no more loosing the filename header for the File Component etc.
Current header name strategy used for accepting header names in Camel:
- replace all dots with underscores (e.g. org.apache.camel.MethodName => org_apache_camel_MethodName)
- test if the name is a valid java identifier using the JDK core classes
- if test success then the header is added and sent over the wire, if not its dropped (logged at DEBUG level)
![]() | For Consuming Messages cacheLevelName settings are vital!
If you are using Spring before 2.5.1 and Camel before 1.3.0 then you might want to set the cacheLevelName to be CACHE_CONSUMER for maximum performance.
Due to a bug in earlier Spring versions![]() causing a lack of transactional integrity, previous versions of Camel and Camel versions from 1.3.0 onwwards when used with earlier Spring versions than 2.5.1 will default to use CACHE_CONNECTION. See the JIRAs CAMEL-163![]() and CAMEL-294![]() .
Also if you are using XA or running in a J2EE container then you may want to set the cacheLevelName to be CACHE_NONE as we have seen using JBoss with TibCo EMS and JTA/XA you must disable caching. |
Properties
You can configure lots of different properties on the JMS endpoint which map to properties on the JMSConfiguration POJO![]()
.
| Property |
Default Value |
Description |
| acceptMessagesWhileStopping |
false |
Should the consumer accept messages while it is stopping |
| acknowledgementModeName |
"AUTO_ACKNOWLEDGE" |
The JMS acknowledgement name which is one of: TRANSACTED, CLIENT_ACKNOWLEDGE, AUTO_ACKNOWLEDGE, DUPS_OK_ACKNOWLEDGE |
| acknowledgementMode |
-1 |
The JMS acknowledgement mode defined as an Integer. Allows to set vendor-specific extensions to the acknowledgment mode. For the regular modes prefer to use the acknowledgementModeName instead. |
| autoStartup |
true |
Should the consumer container auto-startup |
| cacheLevelName |
"CACHE_CONSUMER" |
Sets the cache level name for the underlying JMS resources |
| 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. Its typically only required for durable topic subscriptions. You may prefer to use Virtual Topics![]() instead |
| consumerType |
Default |
The consumer type to use, either: Simple, Default or ServerSessionPool. The consumer type determines which Spring JMS listener should be used. Default will use org.springframework.jms.listener.DefaultMessageListenerContainer. Simple will use org.springframework.jms.listener.SimpleMessageListenerContainer and ServerSessionPool will use org.springframework.jms.listener.serversession.ServerSessionMessageListenerContainer. If option useVersion102=true then Camel will of course use the JMS 1.0.2 Spring classes instead. |
| concurrentConsumers |
1 |
Specifies the default number of concurrent consumers |
| connectionFactory |
null |
The default JMS connection factory to use for the listenerConnectionFactory and templateConnectionFactory if neither are specified |
| deliveryPersistent |
true |
Is persistent delivery used by default? |
| disableReplyTo |
false |
Do you want to ignore the JMSReplyTo header and so treat messages as InOnly by default and not send a reply back? |
| durableSubscriptionName |
null |
The durable subscriber name for specifying durable topic subscriptions |
| exceptionListener |
null |
The JMS Exception Listener used to be notified of any underlying JMS exceptions |
| explicitQosEnabled |
false |
Set if the deliveryMode, priority or timeToLive should be used when sending messages |
| exposeListenerSession |
true |
Set if the listener session should be exposed when consuming messages |
| idleTaskExecutionLimit |
1 |
Specify 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 case of dynamic scheduling; see the "maxConcurrentConsumers" setting). |
| jmsOperations |
null |
Allow to use your own implementation of the org.springframework.jms.core.JmsOperations interface. Camel uses JmsTemplate as default. Can be used for testing purpose, but not used much as stated in the spring API docs. |
| listenerConnectionFactory |
null |
The JMS connection factory used for consuming messages |
| maxConcurrentConsumers |
1 |
Specifies the maximum number of concurrent consumers |
| maxMessagesPerTask |
1 |
The number of messages per task |
| messageConverter |
null |
The Spring Message Converter |
| messageIdEnabled |
true |
When sending, should message IDs be added |
| messageTimestampEnabled |
true |
Should timestamps be enabled by default on sending messages |
| priority |
-1 |
Values of > 1 specify the message priority when sending, if the explicitQosEnabled property is specified |
| selector |
null |
Sets the JMS Selector which is an SQL 92 predicate used to apply to messages to filter them at the message broker. You may have to encode special characters such as = as %3D |
| receiveTimeout |
none |
The timeout when receiving messages |
| requestTimeout |
20000 |
The timeout when sending messages |
| recoveryInterval |
none |
The recovery interval |
| serverSessionFactory |
null |
The JMS ServerSessionFactory if you wish to use ServerSessionFactory for consumption |
| subscriptionDurable |
false |
Enabled by default if you specify a durableSubscriberName and a clientId |
| taskExecutor |
null |
Allows you to specify a custom task executor for consuming messages |
| templateConnectionFactory |
null |
The JMS connection factory used for sending messages |
| timeToLive |
null |
Is a time to live specified when sending messages |
| transacted |
false |
Is transacted mode used for sending/receiving messages? |
| transactionManager |
null |
The Spring transaction manager to use |
| transactionName |
null |
The name of the transaction to use |
| transactionTimeout |
null |
The timeout value of the transaction if using transacted mode |
| useVersion102 |
false |
Should the old JMS API be used |
Concurrent Consuming
A common requirement with JMS is to consume messages concurrently in many threads to achieve high throughput. As shown above you use the concurrentConsumers property above.
e.g.
from("jms:SomeQueue?concurrentConsumers=20").bean(MyClass.class);
You can configure the properties on the JmsComponent if you wish or on specific endpoints via the URI or by configuring the JmsEndpoint directly.
Message format
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 keys:
- Keys stating with JMS or JMSX is reserved. All user keys will be dropped.
- exchange.in.headers keys must be literals and all be valid Java identifiers. (do not use dots in the key name)
- In Camel 1.4 onwards Camel will automatically replace all dots with underscore for key names. And vice-versa when Camel consumes JMS messages.
For the exchange.in.header the following rules apply for the values:
- The values must be primitives or their counter objects (such as Integer, Long, Character). String, CharSequence, Date, BigDecimal or BigInteger is all converted to their toString() representation. All other types is dropped.
Camel will log with category org.apache.camel.component.jms.JmsBinding at DEBUG level if it drops a given header value. 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}
Configuring different JMS providers
You can configure your JMS provider inside the Spring XML as follows...
<camelContext id="camel" xmlns="http://activemq.apache.org/camel/schema/spring">
</camelContext>
<bean id="activemq" class="org.apache.camel.component.jms.JmsComponent">
<property name="connectionFactory">
<bean class="org.apache.activemq.ActiveMQConnectionFactory">
<property name="brokerURL" value="vm://localhost?broker.persistent=false"/>
</bean>
</property>
</bean>
Basically you can configure as many JMS component instances as you wish and give them a unique name via the id attribute. The above example configures an 'activemq' component. You could do the same to configure MQSeries, TibCo, BEA, Sonic etc.
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 as activemq:[queue:|topic:]destinationName. So you could use the same approach for working with 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.
Enabling Transacted Consumption
A common requirement is to consume from a queue in a transaction then process the message using the Camel route. To do this just ensure you set the following properties on the component/endpoint
- transacted = true
- transactionManager = a Transsaction Manager - typically the JmsTransactionManager
See also the Transactional Client EIP pattern for further details.
Using JNDI to find the ConnectionFactory
If you are using a J2EE container you might want to lookup in JNDI to find your ConnectionFactory rather than use the usual <bean> mechanism in spring. You can do this using Spring's factory bean or the new XML namespace. e.g.
<bean id="weblogic" class="org.apache.camel.component.jms.JmsComponent">
<property name="connectionFactory" ref="myConnectionFactory"/>
</bean>
<jee:jndi-lookup id="myConnectionFactory" jndi-name="java:env/ConnectionFactory"/>
Using request timeout
In the sample below we send a request-reply style message (we use the requestBody method = InOut) to the slow queue for further processing in Camel and we wait for a return reply.
Object out = template.requestBody("activemq:queue:slow?requestTimeout=5000", "Hello World");
See Also
