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
