Use the concurrentConsumers option in the JMS consumer to start multiple receiving threads.
Make sure to use the transacted mode to leverage broker-side redeliveries. Like Claus said above, use JMS Message Groups to serialize the processing of messages that share a key. If your producer cannot place the required JMSXGroupId header, create an intermediate route in Camel that (1) picks up the raw messages, (2) calculates the "bucketing key" based on payload data, (3) sets the JMSXGroupId header and (4) publishes the resulting message onto a different JMS queue, where a different Camel route is listening. Seda will preserve the transaction as long as it's not an XA transaction. If your JMS messages are InOnly (no JMSReplyTo header, or replyTo option in the JMS consumer), set the waitForTaskToComplete option to Always on the producer. Otherwise, your JMS message will be ACK'ed to the broker before the JavaSpaces publishing takes place and exceptions will not cause a rollback. Hope this helps, *Raúl Kripalani* Apache Camel PMC Member & Committer | Enterprise Architect, Open Source Integration specialist http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani http://blog.raulkr.net | twitter: @raulvk On Fri, Jul 12, 2013 at 7:10 PM, salemi <sal...@avaya.com> wrote: > Yep, I was thinking about this approach as well. > Using Seda is the transnational integrity preserved? > Let say the delivery of one message using seda fails, does camel recognize > it and redeliver it? > > > > > > ----- > Alireza Salemi > -- > View this message in context: > http://camel.465427.n5.nabble.com/Incoming-message-from-a-JMS-queue-need-to-be-processed-in-parallel-but-keep-the-ordering-of-messages-tp5735406p5735577.html > Sent from the Camel - Users mailing list archive at Nabble.com. >
