On Tue, May 12, 2009 at 10:25 AM, Willem Jiang <willem.ji...@gmail.com> wrote:
> 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
Two minds think alike. I have just updated the design page and moved
the UnitOfWork callbacks from 2.1 to 2.0.
>
> 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
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
--
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
