Agree. I think we went overboard in supporting the same scenarios in multiple
ways. What is convenient syntactic sugar for some is a source of confusion for
many.
My $0.02,
Hadrian
On Aug 9, 2011, at 12:20 PM, Christian Schneider wrote:
> Hi Claus,
>
> without changing anything in camel wouldn´t a simple change in the route also
> work?
>
> from("activemq:queue:inbox?synchronous=true")
> .threads()
> .to("jetty:http://0.0.0.0:9432/myapp";)
> .to("log:result?groupSize=10", "mock:result");
>
> So I ask myself if we really need async support in the jms consumer if we can
> support the scenario using a well known dsl element.
>
> Christian
>
>
> Am 09.08.2011 14:25, schrieb Claus Ibsen:
>> Hi
>>
>> See ticket
>> https://issues.apache.org/jira/browse/CAMEL-3632
>>
>> Take a look at the following routes
>>
>> from("activemq:queue:inbox?synchronous=true")
>> .to("jetty:http://0.0.0.0:9432/myapp";)
>> .to("log:result?groupSize=10", "mock:result");
>>
>> from("jetty:http://0.0.0.0:9432/myapp";)
>> .delay(100)
>> .transform(body().prepend("Bye "));
>>
>>
>> Its a fairly simple flow JMS -> JETTY -> MOCK
>>
>> The JMS consumer will by default be in synchronous mode. Ticket
>> CAMEL-3632 is to optimize this by supporting asynchronous routing if
>> the JMS consumer is *not* transactional, and *not* sending back a
>> reply message.
>>
>> So the scenarios is for high performance one way messaging.
>>
>> The 2nd route above simulate a little processing time, which takes 100
>> millis.
>>
>> If we run a test where we send 1000 messages to the queue. How long
>> time would it take to process those messages synchronously? Of course
>> roughly 1000 * 0.1 sec = 100 sec. On my laptop it takes:
>> Took: 1 minute (105393 millis)
>>
>> Now imagine we set synchronous=false on the JMS consumer so it runs
>> asynchronously. How fast would it then go? Well lets try
>> Took: 10.742 seconds (10742 millis)
>>
>> That is a lot fast, well of couse its about 10x faster, since the JMS
>> consumer is not blocked waiting for the JETTY reply.
>> However the messages is now not processed in sequence, that is the cost.
>>
>> To note in both scenarios this was done with 1 JMS consumer thread. I
>> did not enable concurrentConsumers. So with the async routing engine
>> we could scale and utilize the CPU resources better.
>>
>> This seems like a great addition. And if we add this, we should add
>> some documentation with the pros/cons for using this.
>>
>> My question is what would a sensitive default setting be? Should we
>> let the JMS consumer be kept as synchronous by default, to keep it
>> fully backwards compatible. Then end users must manually set
>> synchronous=false on the JMS endpoint to enable that.
>>
>> Any thoughts?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
