Hi Claus, Thanks for your explanation. Could you add the road map of call back support into the Camel 2.0 Design page[1]?
[1] http://camel.apache.org/camel-20-design.html Willem Claus Ibsen wrote: > On Mon, May 11, 2009 at 9:32 AM, Willem Jiang <willem.ji...@gmail.com> wrote: >> Hi Claus >> >> I really enjoy to read the document that you write. >> You give me a good explanation and compare of Camel Sync and Async >> processing API. >> >> Now I just have quick question for the replacement of old AsyncCallback >> API Done(). >> Let's take the Asynchronous Request Only message sending as an example. >> >> The user could want to know if the request is processed succeed, but he >> doesn't want to his sending client checks every Feature object for >> return message, he just want to register a simple call back method for >> doing some revert work if the message can't be processed rightly. >> >> How can the new Async API help us to implement this user story. > The tip kinda explains that: > > In case you want to know whether the Async Request Only failed, then > you can use the Future handle and invoke get() and if it throws a > ExecutionException then the processing failed. The caused exception is > wrapped. You can invoke isDone() first to test whether the task is > done or still in progress. Otherwise invoking get() will wait until > the task is done. > > > So if you want to check whether an exception occurred or not you can do > > public boolean didTheJobSucceed(Future future) { > try { > future.get(); > return true; > } catch (ExecutionException e) { > return false; > } > } > > But its not 100% what you want as you want a callback that is invoked > when the job is done. > Well the JDK concurrency API does not support that easily. You can not > register custom callbacks, that are automatic invoked when a task is > complete. > > > But dont dispair. In Camel we have the UnitOfWork for that. The idea > is that its where end users and camel components can register > callbacks > when a Camel Exchange is complete or failed. > > We have planned for Camel 2.1 to give this an overhaul as well, so we > got nice syntax sugar in the DSL itself so you can easily add custom > callbacks, that can be camel routes as well. Eg to easily send an > email in case of a route failure. > > In the mean time you can use the UnitOfWork and add a callback > yourself from a processor. > There is a addSynchronization method on the UoW > > exchange.getUnitOfWork().addSynchronization(mySync) > > > So Willem we will get this improved in the future as well. You can do > it now but will be easier and nicer in Camel 2.1. > Or if we find the time then we can maybe make it for 2.0 as well. I > guess the main problem before holding it back was the old Async API > that just got to complex and broken. So I do envision it should be not > that hard to do now. > > >> BTW, Since Spring store the transaction information in the thread local >> variable , we need to make sure the rollback method is called in the >> same thread, so this is common user story in camel. > > Yeah for transactions you should not mix threads. This problem can > occur if you use the async() DSL as it will submit a new task that are > executed in a new thread. But for the client API using the > ProducerTemplate there are no problem, as the transaction should > usually not span both the client + "camel". > > But for sure that is something you should consider when doing transactions. > > Everyting has its pros/cons. Also async messaging. > > > >> Willem >> >> Claus Ibsen wrote: >>> On Fri, May 8, 2009 at 8:52 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: >>>> On Wed, May 6, 2009 at 3:41 PM, Gert Vanthienen >>>> <gert.vanthie...@gmail.com> 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 <claus.ib...@gmail.com>: >>>>>> Hi >>>>>> >>>>>> Status update >>>>>> >>>>>> On Wed, May 6, 2009 at 9:17 AM, Claus Ibsen <claus.ib...@gmail.com> >>>>>> 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 >>>> >>> >>> >> > > >
