Hi
On Mon, May 25, 2009 at 9:28 AM, Claus Ibsen <claus.ib...@gmail.com> wrote:
> On Mon, May 25, 2009 at 9:00 AM, huntc <hu...@mac.com> wrote:
>>
>> Hi Claus,
>>
>> As per your blog request, I'd like to discuss the virtues of naming the
>> async method "async" vs treating your 2.0 functionality as a new
>> implementation of the existing "thread" method.
Okay I got good tunes on iTunes so was in the mood to take a stab at this.
Got the seda endpoint to support request/reply where it waits for the
route to be complete before returning from the original caller.
So you can do:
from("direct:start").to("seda:a");
from("seda:a").to("log:bar", "seda:b");
from("seda:b").delay(10).to("direct:c");
from("direct:c").transform(constant("Bye
World")).to("mock:result");
And the very first message we sent to direct:start that goes to seda:a
will wait at seda:a until the message exchange is complete if its a
request/reply message.
So what we get is the "Bye World" as response.
I will later add the same options as the *threads* DSL so you can
overrule this behavior. Eg to not wait for a reply if you dont care.
Christopher dont say we do not listen to the community. Thanks for the feedback.
>>
>> When I think about concurrency I think about multiple threads of execution -
>> not whether something is asynchronous. You can have something being
>> asynchronous without it being multi-threaded e.g. Javascript's
>> XmlHttpRequest.
>>
>> Thread also implies just one thread. Perhaps renaming async to "threads" and
>> deprecating "thread" may be the way to go? Specifying "threads" without a
>> thread pool size should perhaps default to the number of processors + 1 as a
>> rule... (as per MINA?).
>
> Good points. threads is a good name as well. And afterall the async
> DSL is capable of waiting for a response so it behaves like a single
> synchronous request/reply from the caller perspective. So using
> threads could be a better name.
>
> I have added your idea of the defaults for number of threads in the
> pool to the 2.x design page
> http://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 from the Camel Development mailing list archive at Nabble.com.
>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
