camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gert Vanthienen <>
Subject Re: Camel 2.0 Async Findings - Roadmap to a solution
Date Wed, 06 May 2009 13:41:38 GMT
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,
- 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.


Gert Vanthienen
Open Source SOA:

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

View raw message