camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Camel 2.0 Async Findings - Roadmap to a solution
Date Mon, 11 May 2009 07:50:33 GMT
On Mon, May 11, 2009 at 9:32 AM, Willem Jiang <> 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 {
  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

But dont dispair. In Camel we have the UnitOfWork for that. The idea
is that its where end users and camel components can register
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


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 <> wrote:
>>> On Wed, May 6, 2009 at 3:41 PM, Gert Vanthienen
>>> <> 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.
>>> 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:
>>>> Blog:
>>>> 2009/5/6 Claus Ibsen <>:
>>>>> Hi
>>>>> Status update
>>>>> On Wed, May 6, 2009 at 9:17 AM, Claus Ibsen <>
>>>>>> 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:
>>> Blog:
>>> Twitter:
>>> Apache Camel Reference Card:
>>> Interview with me:

Claus Ibsen
Apache Camel Committer

Open Source Integration:
Apache Camel Reference Card:
Interview with me:

View raw message