camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Moulliard <cmoulli...@gmail.com>
Subject Re: [DISCUSS] - JmsConsumer support for asynchronous routing engine - Higher scalability
Date Wed, 10 Aug 2011 09:12:26 GMT
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.

Just 2 cents to the debate.

Regards,

Charles


On Tue, Aug 9, 2011 at 2:25 PM, Claus Ibsen <claus.ibsen@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: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>

Mime
View raw message