Awesome work. This should really provide a huge scalability boost for some folks!
On Thu, Jul 1, 2010 at 7:58 AM, Claus Ibsen <claus.ib...@gmail.com> 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 > https://issues.apache.org/activemq/browse/CAMEL-2723 > > 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: http://www.manning.com/ibsen/ > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > Twitter: http://twitter.com/davsclaus > -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://fusesource.com/
