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.vah...@swissonline.ch>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. > > >
