First of all many thank to you all for your suggestions, I was available to
come up with an scalable solution and our chief architect even accepted
thesolution. I can ask the JMS producers to add the JMSXGroupID header as
well as an additional header to use as an selector.
As Claus suggested we will use the JMSXGroupID header and will deploy
multiple consumers. To avoid the time spent in the splitter I decided to
remove the choice and use JMS selectors instead (see below).
<route id="1">
<from
uri="{{operational.topic.prefix}}.{{source.type}}.{{source.name}}?concurrentConsumers=2&
amp;selector=MessageType='x1'" />
...
<route id="2">
<from
uri="{{operational.topic.prefix}}.{{source.type}}.{{source.name}}?concurrentConsumers=2&selector=MessageType='x2'"
/>
..
The only concern remains how ActiveMq performs since I am combining
selectors and group.
So far I have seen almost linear scalability by adding a new consumer. I
have done testing with 11 concurrent consumer which is enough for our
purposes.
-----
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-tp5735406p5737226.html
Sent from the Camel - Users mailing list archive at Nabble.com.
