Hi Yes SedaProducer waits for the reply in a sync fashion *but* it's done through leveraging the asynchronous model and this's what the documentation for async routing engine says:
"When we say a component is supported, that means, the component is leveraging the asynchronous model." So to my understanding it means a Producer supports the async routing engine *if* it makes use of it's API, e.g. as soon as a Producer extends DefaultAsyncProducer so that it's *forced* to implement the method signature: public boolean process(final Exchange exchange, final AsyncCallback callback); Which to me means "leveraging the asynchronous model". Babak Willem.Jiang wrote > Hi > > Current camel-seda component doesn't support the Async Routing Engine. > The call in the producer is synchronized as Raul already point out. > > But it is common practice to implement concurrency processing by > leveraging the blocking Queue with a thread pool. > And we should make us clear about it instead of putting the camel-seda > component into Async Routing Engine catalog. > > -- > Willem Jiang > > Red Hat, Inc. > FuseSource is now part of Red Hat > Web: http://www.fusesource.com | http://www.redhat.com > Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) > (English) > http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese) > Twitter: willemjiang > Weibo: willemjiang > > > > > > On Wednesday, September 26, 2012 at 5:57 AM, Raul Kripalani wrote: > >> Hi Babak, >> >> What I'm trying to say is that, despite the use of several concurrency >> constructs to decouple the producer from the consumer it is ultimately >> communicating with (in-VM), all work is really executed synchronously >> from >> the point of view of the producer. >> >> In fact, the calling thread will block until the response is received if >> it's an InOut interaction. That is contrary to the philosophy of the >> Async >> Routing Engine. So, if my suspicion is correct, the Seda producer >> shouldn't >> be advertised as supportive of the Async Routing Engine here [1]. >> >> What's more, the roadmap for Camel 3.0 includes making the Seda Component >> (and the VM variant) leverage the Async Routing Engine [2]. >> >> So shall we remove the Seda component from [1]? Right now, there's >> incoherency between [1] and [2] unless I've overlooked some nuance. >> >> Regards, >> Raúl. >> >> [1] http://camel.apache.org/asynchronous-routing-engine.html. >> [2] >> http://camel.apache.org/camel-30-roadmap.html#Camel3.0-Roadmap-SEDA%2FVMcomponentstoleverageasyncroutingengine >> . >> >> On Sun, Sep 23, 2012 at 2:32 PM, Babak Vahdat >> < > babak.vahdat@ > (mailto: > babak.vahdat@ > )>wrote: >> >> > > Hi fellow riders, >> > >> > > The async routing engine page in the docs [1] suggests that the SEDA >> > > Producer is async. >> > > I may be slightly confused, but I don't see the SedaProducer >> returning >> > > "false" in its process() method at any point (overridden from >> > > DefaultAsyncProducer). >> > >> > >> > >> > >> > BTW the method is *not* overridden from DefaultAsyncProducer because it >> > does not implement the process method signature with 2 arguments from >> the >> > AsyncProcessor interface at all. >> > Actually the reason why it's marked to be abstract. >> > >> > Babak >> > >> > > In fact, all unit tests that require the async routing engine to be >> in >> > > place use a utility component called MyAsyncComponent, rather than >> SEDA. >> > >> > >> > >> > > Am I missing something? >> > >> > > [1] http://camel.apache.org/asynchronous-routing-engine.html >> > >> > > Thanks! >> > > Raúl. >> > >> -- View this message in context: http://camel.465427.n5.nabble.com/Is-the-SEDA-producer-really-async-tp5719791p5719995.html Sent from the Camel Development mailing list archive at Nabble.com.
