On Wed, Aug 10, 2011 at 11:12 AM, Charles Moulliard <cmoulli...@gmail.com> wrote: > Hi Claus, > > I would prefer that we follow the same convention for JMS, NMR and all > related components. As they are by default async (This is why we use a > MOM or NMR bus), the producer and consumer should be also defined as > asynchronous by default and changed by the user when they would like > to switch to synchronous mode. >
A good idea. Having slept on this I also lean towards this, to keep it consistent with the other components that supports asynchronous routing engine. http://camel.apache.org/asynchronous-routing-engine.html > Just 2 cents to the debate. > > Regards, > > Charles > > > On Tue, Aug 9, 2011 at 2:25 PM, Claus Ibsen <claus.ib...@gmail.com> wrote: >> 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? >> >> >> >> >> >> >> >> >> >> -- >> Claus Ibsen >> ----------------- >> FuseSource >> Email: cib...@fusesource.com >> Web: http://fusesource.com >> Twitter: davsclaus, fusenews >> Blog: http://davsclaus.blogspot.com/ >> Author of Camel in Action: http://www.manning.com/ibsen/ >> > -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
