camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiram Chirino <>
Subject Re: Asynchronous Routing Engine - Status
Date Fri, 02 Jul 2010 13:06:49 GMT
Awesome work.  This should really provide a huge scalability boost for some

On Thu, Jul 1, 2010 at 7:58 AM, 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.
> 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:



Open Source SOA

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message