://cwiki.apache.org/confluence/display/CAMEL/Camel+2.0+Design
We have improved thread pool configuration on the roadmap for 2.1.
Thoughts?
Kind regards,
Christopher
--
View this message in context:
http://www.nabble.com/Camel-2.0-Async-Findings---Roadmap-to-a-solution-tp23310165p23702159.html
Sent
+2.0+Design
We have improved thread pool configuration on the roadmap for 2.1.
Thoughts?
Kind regards,
Christopher
--
View this message in context:
http://www.nabble.com/Camel-2.0-Async-Findings---Roadmap-to-a-solution-tp23310165p23702159.html
Sent from the Camel Development mailing
and configuration of Camel planned for 2.1
Thoughts?
Kind regards,
Christopher
--
View this message in context:
http://www.nabble.com/Camel-2.0-Async-Findings---Roadmap-to-a-solution-tp23310165p23702159.html
Sent from the Camel Development mailing list archive at Nabble.com.
--
Claus Ibsen
default to the number of processors + 1 as a
rule... (as per MINA?).
Thoughts?
Kind regards,
Christopher
--
View this message in context:
http://www.nabble.com/Camel-2.0-Async-Findings---Roadmap-to-a-solution-tp23310165p23702159.html
Sent from the Camel Development mailing list archive
for 2.1.
Thoughts?
Kind regards,
Christopher
--
View this message in context:
http://www.nabble.com/Camel-2.0-Async-Findings---Roadmap-to-a-solution-tp23310165p23702159.html
Sent from the Camel Development mailing list archive at Nabble.com.
--
Claus Ibsen
Apache Camel Committer
Open
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
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
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
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
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
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
Hi
Just wanted to keep you posted.
Had some more work done to replace the old async API with the new API
in camel-core.
I basically got it all done except the MuticastProcessor as it would
take a bit more time to get done correctly.
I am thinking it should leverage the JDK CompletionService or
I have committed a patch to trunk:
that resolves #1 (partly), #2 and #4
In #1 there are still two classes that needs a cleanup as well.
However they are core pieces in Camel, the Pipeline and
MulticastProcessor so they are left as is. When we have a new Async
API in place these classes can be
Hi
This is just a short update on:
Ad 3)
The new Async API
I started iTunes with some good tunes from my youth gone wild period,
so I had a crack at prototype of the async API.
Here is the first unit test demonstrating how it could work with the
JDK Future API (for real async)
public class
Hi
Just another update on #3. I had some more fun with Camel and
introduced a async() DSL in the route, to turn the route into async
from the point forward.
The unit test code explains it, and gives a hint how we can leverage this.
Any thoughts?
public class AsyncRouteTest extends
Hi
Its me again. Yeah I am due for a run in due time, but just wanted to
demo something that is either powerful or scary
The code below uses the same route. But as we request a body and we
have declared we want the response as a String.class (the last
parameter)
Then Camel is clever or scary to
Hi Claus,
Does the async() DSL will fork a thread for the further processing?
What's the difference between the async() DSL and send the message to a
seda endpoint?
Thanks,
Willem
Claus Ibsen wrote:
Hi
Just another update on #3. I had some more fun with Camel and
introduced a async() DSL
On Thu, Apr 30, 2009 at 4:05 PM, Willem Jiang willem.ji...@gmail.com wrote:
Hi Claus,
Does the async() DSL will fork a thread for the further processing?
What's the difference between the async() DSL and send the message to a
seda endpoint?
Yes it forks a thread. Its the JDK Executor that
On Thu, Apr 30, 2009 at 4:00 PM, Willem Jiang willem.ji...@gmail.com wrote:
How about introducing Async requestBody API to the template?
It just return a Future object, then we can turn the value of Future
into what we want.
Good idea. In fact I have done that already.
FutureObject
Hi
I have uploaded a 2nd patch at CAMEL-1572 - (the b patch)
I got the async API prototype also.
On Thu, Apr 30, 2009 at 5:39 PM, Claus Ibsen claus.ib...@gmail.com wrote:
On Thu, Apr 30, 2009 at 4:00 PM, Willem Jiang willem.ji...@gmail.com wrote:
How about introducing Async requestBody API to
20 matches
Mail list logo
