camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Asynchronous Routing Engine - Status
Date Fri, 02 Jul 2010 14:43:29 GMT
On Fri, Jul 2, 2010 at 4:34 PM, Guillaume Nodet <> wrote:
> Great work, Claus!
> On Thu, Jul 1, 2010 at 13:58, Claus Ibsen <> wrote:
>> Hi
>> The major goal for Camel 2.4 is introducing back the asynchronous
>> routing engine from the Camel 1.x days.
>> What we had replaced it with, just didn't cut it for the long run, so
>> we had to toss it out and replace it back with the 1.x variation.
>> However the 1.x variation is much more invasive in the camel core.
>> However the benefits are worth it.
>> There is a JIRA ticket to track this
>> We got so far with the code that we can move ahead the release
>> schedule for 2.4 and thus why Hadrian send out
>> an announcement yesterday.
>> The engine has been integrated with Apache ServiceMix JBI and NMR,
>> which means that in SMX 4.3 and Came. 2.4 onwards
>> you have much better scalability and utilization of the resources.
>> There is present only a single Camel component which leverages the
>> async routing as well which is Jetty.
>> The consumer side uses Jetty continuations and the producer side the
>> Jetty http async client.
>> We plan to expand this to other Camel components where async
>> communication is native supported by the component.
>> Such as Netty, Mina 2 (when its out), CXF producer, REST stuff and what else.
>> Mind that async routing does not work to the fullest if you are not
>> using transactions. Spring TM requires the transactional resources to
>> be
>> executed from the same thread context, which is why Camel will
>> fallback to route fully synchronous if you use transacted routes.
>> This works automatic and you dont have to worry about it to configure
>> any of the Camel endpoints to cater for this. It's just that Camel
>> will have the caller thread blocked while waiting for the async reply,
>> in case you for example to request/reply over NMR in a transaction.
> We might be able to alleviate this limitation. I know the spring
> transaction layer can suspend and resume transactions in different
> threads.
> I've done this kind of integration already: see the
> registerTransactionAssociationListener method in the following class

Fantastic this looks great. I have created a ticket to track it

Also there is another ticket with a related feature for the Spring
DMLC to handle the JMS ACKs yourself.

So I think in Camel 2.5 we should be able to work on supporting async
TX as well at some level.

>> Almost all the EIP patterns in Camel have been refactored to support
>> async routing engine as well. So you can use Splitter, Recipient List,
>> WireTap
>> and all the others in the most optimal way. Currently there are 3
>> outstanding works to be looked at:
>> - Throttler and Delayer EIP to not block while waiting
>> - Multicast, Recipient List and Splitter EIP to support async routing
>> engine when parallelProcessing option is enabled (this is a bit tricky
>> to do).
>> - RedeliverErrorHandler to use non blocking while waiting for delivery
>> (current only enabled if async routing has been kicked in) but we can
>> do this in a general.
>> --
>> Claus Ibsen
>> Apache Camel Committer
>> Author of Camel in Action:
>> Open Source Integration:
>> Blog:
>> Twitter:
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog:
> ------------------------
> Open Source SOA

Claus Ibsen
Apache Camel Committer

Author of Camel in Action:
Open Source Integration:

View raw message