# JMS Part Two; tuning behaviour

JMS is the bread and butter of the adapter; it’s been supported even since it was first released. We use JMS as the backbone of all our community deployments; we aren’t picky about the vendor, so long as it supports JMS 1.0 then the adapter will quite happily work with it. I’ve written previously about JMS Connections and the adapter. Most of time, it just works; the problems that you might be having will be configuration based because the default behaviour just aren’t suitable for your environment.

## JMS Message Types and translation

All the standard JMS types are supported, BytesMessage, TextMessage, MapMessage, ObjectMessage are supported in the adapter via their associated MessageTypeTranslator implementations. Of course, vendor specific message types are also supported; such as Progress SonicMQ’s XMLMessage type. There’s also AutoConvertMessageTranslator which is primarily useful when configuring a consumer. By convention, we like you to know what type of message is being delivered onto the JMS destination that the adapter is receiving messages from; of course, sometimes there might be a mix of message types, or maybe you just don’t know. AutoConvertMessageTranslator automagically handles the standard types by delegating to the correct MessageTypeTranslator implementation so if it thinks the javax.jms.Message is a TextMessage then it will delegate to TextMessageTranslator. The mapping from MapMessage is quite simplistic: all name value pairs are assumed to be strings, and they are converted directly into metadata; the resulting payload is empty.

The JMS correlation ID is used, well for correlating things; typically a request with a reply message. If you need to handle the correlation id, then you need to configure a CorrelationIdSource implementation. The default is NullCorrelationIdSource which essentially ignores this JMS Header.

So if you wanted to force replies to a given message to come back on MyReplyToDestination then the configuration you need is something similar to this :

• JMSExpiration - this will be used to generate the correct TTL when producing the message. The format of this value should either be a long value (similar to System.currentTimeMillis(), the difference, measured in milliseconds, between the current time and midnight, January 1, 1970 UTC); or a string value in the date format yyyy-MM-dd'T'HH:mm:ssZ.
Powered by Hydejack v6.6.1