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 Wed, 06 May 2009 14:00:16 GMT
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?

Per see the two are unrelated as such. But in the future we can much
more easily introduce async channels.
If you want for instance each processing step to be done async step by step :)

But currently the Channel we have is not so flexible but the ground
work has been done for the future work.

> - 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?
Note the async DSL I did in the patch was an experiment but will bring
it back in to replace the old Thread DSL.

Well the original thread gets the Future<Exchange> handle as a result.
So it basically returns this back to the original caller.
Then the original caller can do other work, and then retrieve the
async thread result when he/she likes with the future handle get

> - 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?
Good question. I am also aligning the configuration of thread pools in
Camel 2.0. So its based on ExecutorService and have the same API /
Spring attribute.
This allows end users to define thread pools as they like more easily
and configure it.

And at the same time we should provide some default pools and pool
sizes. Some uses 5 and others 10 in the current code base. But
basically each processor creates its own thread pool if none
configured, and they default to a size of either 5 or 10.

When I get a bit more work done lets re asset and find a good solution
for thread pool management in Camel 2.0

For instance some users with J2EE servers would like to define that
Camel should use threads provided from this server.


> 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.
I guess we have enough work just to keep the Scala DSL up to date. But
yeah concurrency and parallel work is challeging the way we program
today in Java.
Bug be careful James might read this and ask you to do some prototyping :)

> 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 <> 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
>>> - Remove last piece of old API classes (2 interfaces)
>>> - 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:
Apache Camel Reference Card:
Interview with me:

View raw message