On Wed, May 12, 2010 at 00:53, Claus Ibsen <claus.ib...@gmail.com> wrote:
> > You can use the ToAsync > http://camel.apache.org/toasync.html > > It leverages the AsyncProcessor API which you know from Camel 1.x. > > However it hasn't been full implemented and expanded to included other > Camel components than Jetty at the moment. > We got tickets in JIRA to improve this. > > Sorry if my email was a bit harsh. Let me explain what I think the problem is. In camel 1.6.x, we had support for the AsyncProcessor. I know it was not fully complete, but the jetty consumer was working and there was an initial work done on the jhc component. Remember at that time, the jetty client did not exist at all iirc, so jhc was the only asynchronous http client available. It may have not been perfect and I agree there was a need to improve it. But it was fullfilling a need which I think is not covered anymore. The AsyncProcessor was not intented to be used by users, it was an implementation detail. The goal was really the following: let's say i have the following route from("http:xxx").something().to("jms:yyy").anotherthing().to("http:zzz") the purpose of the async api was to make sure this route could scale when using request-response. What was happening (on the jetty consumer side) was that continuations were leveraged. The jetty would receive an http request. The request would have been processed and ultimately go to the jms component. The jms AsyncProcessor would have sent the jms message and returned false to indicate the response was not available yet. When the jms component would have received the response, the route would have continued because of the call of the asynchronous callback. The same thing would have happened on the http provider. This would have saved threads, hereby making the route more scalable. So the goal was to make that happen transparently without the user even being aware, because in this case, the user does not use a producer template to send an exchange. It's just a camel route definition. What happens now (correct me if i'm wrong), is that you need to use toAsync on a producer, which has the following effect: * if the producer implements AsyncProcessor, it will be called asynchronously using the process(Exchange exchange, AsyncCallback callback) method * if the producer does not support AsyncProcessor, a new thread is spawn and the process(Exchange exchange) method is called followed by the callback In all cases, the response can't be conveyed back because the above processing happens in another thread. So the to() and toAsync() verbs are actually really different. The toAsync() one will spawn a new thread and continue the processing while forgetting about any possible response. So keeping away any argument, is there any way to make a simple route such as from("jetty:http://localhost:8080/service1";).to("jetty:http://localhost<http://localhost/service-impl> :8080/service2").to("jetty:http://localhost <http://localhost/service-impl> :8080/service3"); scalable in a way that the consumer thread would not be block while waiting for the answer of the web service called, and still make sure that the answer is conveyed back to the client ? >From an api perspective, using the asyncCallback calls on the producer template could make sense, the problem is that they just spawn a thread, send the exchange, block for the answer and call the callback. That does not really help scaling from a thread usage perspective. > > > > -- > > Cheers, > > Guillaume Nodet > > ------------------------ > > Blog: http://gnodet.blogspot.com/ > > ------------------------ > > Open Source SOA > > http://fusesource.com > > > > > > > > > > > > -- > > Cheers, > > Guillaume Nodet > > ------------------------ > > Blog: http://gnodet.blogspot.com/ > > ------------------------ > > Open Source SOA > > http://fusesource.com > > > > > > > > > > -- > > Cheers, > > Guillaume Nodet > > ------------------------ > > Blog: http://gnodet.blogspot.com/ > > ------------------------ > > Open Source SOA > > http://fusesource.com > > > > > > -- > Claus Ibsen > Apache Camel Committer > > Author of Camel in Action: http://www.manning.com/ibsen/ > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > Twitter: http://twitter.com/davsclaus > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
