Hi Just to update the status that today I have implemented
a) error handler will now schedule delayed redeliveries by default which thus allows to not block while the delay occurs. You can disable this behavior using the syncDelayed() option on the error handler / onException / routePolicy. And if you use transactions it will use synced delays to ensure the exchange will use the same thread again as the Transaction Manager requires to execute in the same thread context. b) delay and throttle EIP now have an option asyncDelayed() you can use to enable them to use non blocking delay as well The only question though would be if we should have an option to allow you to cancel tasks on shutdown. If you have messages queued up in the delay/throttle. Then a fast stop to cancel the pending tasks is possible. However the JDK ExecutorService API is damn poor in terms of stopping the thread pool. You can only shut it down which then cant restart it. And getting the pending tasks is also not possible unless you gather the Future references and then remember to keep this list up to date removing the done tasks. On Thu, Jul 1, 2010 at 1:58 PM, 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 > -- 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
