On Fri, May 8, 2009 at 8:52 AM, Claus Ibsen <[email protected]> wrote: > On Wed, May 6, 2009 at 3:41 PM, Gert Vanthienen > <[email protected]> wrote: >> Hi Claus, >> >> Nice work on cleaning up the async API for Camel! Using well-known >> java.util.concurrency classes to build the API is a good idea, makes >> it a lot more comprehensible for people. Just a few questions that >> come to mind... >> - How does this work relate to introducing the Channel API? Will we >> have a means for using async channels in the route transparently or >> are the two unrelated? > >> - What happens with the original thread after the async()? I'm >> guessing it will wait for the async work to be done before continuing, >> right? > > I have just committed some improvements to the async DSL. > There is an option you can configure: waitForTaskToComplete. > > This option is an enum accepting 3 options > - Always > - Newer > - IfReplyExpected > > The first two options is self describing. > The last one will wait if the exchange is OUT capable, otherwise not. > > The current default is Always, I have given it some more thought and changed the default to IfReplyExpected, as its kinda what eg. JMS Mina and other components also does already.
BTW: I have created a new wiki page for all this new Async API. Anyone care to read and review is much appreciated. http://camel.apache.org/async > > However I am wondering if the default should be IfReplyExpected instead? > Then it works as JMS, Mina etc. that also only wait if a reply is expected. > > What do people think? > > Okay what is the difference between Always and IfReplyExpected then? > If for instance we send an InOut message then there are no difference, > they both wait. > > However if we send an InOnly then only Always will wait. So what can > that be used for? > Well in case the async task failed with an exception, and since we > wait, we will be notified > of this exception and have a chance to react then. That is the difference. > > Any thoughts? > > > > >> - Do all the threads come from a single thread pool? Do we have a >> means to configure that pool? I guess my main question is, how likely >> are we to deadlock the entire Route by having all the threads either >> waiting on some Future or waiting to get another thread from the pool? >> >> Just wondering if we could somehow put an Erlang-style message-passing >> concurrency mechanism underneath our Route afterwards -- in a >> transparent way so people wouldn't have to worry about this. >> >> Regards, >> >> Gert Vanthienen >> ------------------------ >> Open Source SOA: http://fusesource.com >> Blog: http://gertvanthienen.blogspot.com/ >> >> >> >> 2009/5/6 Claus Ibsen <[email protected]>: >>> Hi >>> >>> Status update >>> >>> On Wed, May 6, 2009 at 9:17 AM, Claus Ibsen <[email protected]> wrote: >>>> Hi >>>> >>>> I have committed first cut of the new Async API to Camel trunk. >>>> See ticket CAMEL-1572 for svn revision and details. >>>> >>>> The remaining work: >>>> - Migrate MulticastProcessor >>> DONE >>> >>>> - Remove last piece of old API classes (2 interfaces) >>> DONE >>> >>>> - Introduce Async DSL to replace Thread DSL and with clear intention >>>> of turning route into async mode and support thread pools using JDK >>>> executor service. >>>> - Support Jetty continuation with async >>>> >>> >> > > > > -- > Claus Ibsen > Apache Camel Committer > > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > Twitter: http://twitter.com/davsclaus > Apache Camel Reference Card: > http://refcardz.dzone.com/refcardz/enterprise-integration > Interview with me: > http://architects.dzone.com/articles/interview-claus-ibsen-about?mz=7893-progress > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus Apache Camel Reference Card: http://refcardz.dzone.com/refcardz/enterprise-integration Interview with me: http://architects.dzone.com/articles/interview-claus-ibsen-about?mz=7893-progress
