Hi The issue is tracked at CAMEL-825 https://issues.apache.org/activemq/browse/CAMEL-825
I have just committed the implementation and updated the wiki pages. Now both the seda and vm component work with request/reply, waiting for the reply. I added options to the endpoint, so you can control this behavior, just like the threads DSL (part of the new Async API). http://camel.apache.org/async.html One feature we could consider is to add timeout support. Currently it will wait until the route is comlete, regardless how long it takes. On Fri, May 29, 2009 at 5:14 PM, Claus Ibsen <claus.ib...@gmail.com> wrote: > 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 > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
