The type of exchange created by a JMS consumer endpoint depends on the value of
the JMSReplyTo
header in the incoming message. If the
JMSReplyTo
header is absent from the incoming message, the consumer
endpoint produces exchanges with the InOnly message exchange
pattern (MEP). For example, consider the following route that receives a stream of
stock quotes from the queue, queue:rawStockQuotes
, reformats the
incoming messages, and then forwards them to another queue,
queue:formattedStockQuotes
.
from("jmstx:queue:rawStockQuotes") .process(myFormatter) .to("jmstx:queue:formattedStockQuotes");
Routes that process InOnly exchanges can easily be combined
with transactions. In the preceding example, the JMS queues are accessed through the
transactional JMS instance, jmstx
(see Configuring the JMS Component). The transaction initiated by the
consumer endpoint, jmstx:queue:rawStockQuotes
, ensures that each
incoming message is reliably transmitted to the producer endpoint,
jmstx:queue:formattedStockQuotes
.
Typically, a route designed to work for InOnly exchanges does
not work properly for InOut exchanges.
Unfortunately, this leaves the route at the mercy of the external JMS client: if the
client should accidentally set a JMSReplyTo
header, the JMS consumer
endpoint will create an InOut exchange, which could lead to
errors in a route that is designed for InOnly exchanges.
To avoid the risk of creating InOut exchanges when they are
not wanted, you can use the disableReplyTo
option in the JMS consumer
to enforce the InOnly MEP. For example, the following route is
guaranteed to process all incoming messages as InOnly
exchanges:
from("jmstx:queue:rawStockQuotes?disableReplyTo=true")
.process(myFormatter)
.to("jmstx:queue:formattedStockQuotes");
Figure 3.1 shows an overview of a scenario consisting of JMS consumer endpoint feeding into a route that ends with a JMS producer endpoint. This route is designed to process exclusively InOnly exchanges.
Messages coming into the route shown in Figure 3.1 are processed as follows:
When a oneway message (
JMSReplyTo
header is absent) is polled by the JMS consumer endpoint, the endpoint starts a transaction, provisionally takes the message off the incoming queue, and creates an InOnly exchange object to hold the message.After propagating through the route, the InOnly exchange arrives at the JMS producer endpoint, which provisionally writes the exchange to the outgoing queue.
At this point, we have arrived at the end of the transaction scope. If there were no errors (and the transaction is not marked for rollback), the transaction is automatically committed. Upon committing, both of the JMS endpoints send acknowledgement messages to the queues, turning the provisional read and the provisional write into a committed read and a committed write.