On Wed, May 12, 2010 at 04:21, Claus Ibsen <claus.ib...@gmail.com> wrote:
> On Wed, May 12, 2010 at 10:57 AM, Guillaume Nodet <gno...@gmail.com> > wrote: > > On Wed, May 12, 2010 at 03:30, Claus Ibsen <claus.ib...@gmail.com> > wrote: > > > >> On Wed, May 12, 2010 at 9:25 AM, Guillaume Nodet <gno...@gmail.com> > wrote: > >> > 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. > >> > >> Well it was not documented anywhere, and as such it was kept in the > dark. > >> It would have been good if you had taken the time to finished what you > >> started > >> or make sure someone could take over and get it up to an acceptable > level. > >> > >> > >> > >> > 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 > >> > >> Adding support for leveraging Jetty continuations is something we can > >> introduce back in Camel 2.x > >> but then as you say it should be part of a larger game plan. > >> > >> > >> > 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. > >> > > >> > >> In Camel 1.x its only the camel-jhc and camel-spring-integration > >> component which implements and uses AsyncProcessor. > >> > >> So the JmsProducer will block and wait for the reply. > >> And the same would the HttpProducer, but as you said at that time JHC > >> was maybe the only async HTTP framework out there). > >> > > > > But the jetty http consumer did call the AsyncProcessor. As I said, that > > was not really supposed to be used by end user. > > > > > >> > >> > >> > >> > >> > 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. > >> > > >> > >> I dont see the difference between 1.x and 2.x here. They both define a > >> Camel route. > >> > >> > >> > 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. > >> > > >> > >> Its acts the same. They both transfer the Exchange to another thread > >> to continue processing it. > >> The difference is the former leverages some native async API from the > >> given component in question. > >> The latter will fallback to a simulated mode from camel-core. > >> > >> > >> > 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. > >> > > >> > >> Yeah toAsync lacks better feedback to the caller in terms of the > response. > >> This is something we have to look into and improve. > >> I have updated the ToAsync wiki page with a notice about this, to make > >> it more public. > >> > >> Also the ToAsync was add to try to facilitate native async support > >> from the various components. > >> - CXF > >> - JBI > >> - Jetty > >> - Apache HTTP Client 4.x > >> - And other HTTP based > >> - Maybe MINA / Netty and others > >> > >> We only got around to have a single proof of concept with the Jetty > >> component. > >> Its subject to changes. > >> If it lies doormat for a long time it will be @deprecated and removed. > >> > >> And maybe in the mean time we come up with better solutions. > >> Such as having this discussion. > >> > >> > >> > 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 ? > >> > > >> > >> I assume you need Jetty Continuations to have the JettyConsumer not > >> block at all? > >> Or am I wrong? > >> > >> If so no there is no way then. > >> Currently the JettyConsumer will at some time block / wait for the > >> reply to get done. > >> > > > > That's precisely what the continuations are used for. And that was > exactly > > what the AsyncProcessor was enabling. > > > > Yeah Jetty continuations has this "park" and "resume" feature which > its the only component which had. > And its great that it will be standard in Servlet 3.0. > > > > > I think you still don't understand what i'm trying to achieve. > > What i want is the following diagram: > > > http://camel.apache.org/asynchronous-processing.data/simple-async-route.png > > Just replace jhc by the jetty producer. > > > > If you block the thread in any way in this diagram, you can't scale to > > thousands of concurrent http clients, because you would need a thousands > of > > threads. > > Asynchronous processing of http requests has been available since jetty 6 > > and has now been brought into Servlet 3.0. > > > > That's the way CXF works. That's also the way ServiceMix works. It's > also > > the way Synapse works. > > > > > > So please don't tell me this is not possible at all. It's just not > possible > > anymore right now. > > > > Yes Jetty continuations is not leveraged in Camel 2.x. > Its something which can be implemented again, and there has been a > TODO in there since we created Camel 2.0. > > There has and are many other things to look at. And people would most > likely have used SMX or CXF for their high scalable HTTP based > services. > That said its of course something that can be prioritized at Camel as > well and if we add the needed muscle to implement it. > > > > > > > > >> > >> > 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. > >> > > >> > >> Where do you mean it blocks? Yeah the spawned thread processes it as > >> normally would do. > >> And invoke the callback when the reply is ready. > >> > >> The caller, however, is not blocked and can continue doing what it may > >> want to do. > >> It got a Future handle in case it wants to access the response as well. > >> > >> > > Well, that's a use case that could have been very easily handled by the > > client itself by spawning it's own thread. > > > > Its not that easy for end users to spawn their own threads and whatnot. > Having a single method is handy, hence the Template pattern. > > > > > Again, I'm not talking about the client being blocked or not blocked > during > > the processing of the message. I'm talking about not waiting for a long > > time for a response when we could just park the exchange and process it > > later when the response comes back. > > > > Yeah got the idea about the park and resume. > > I wonder how it would be possible to do that in a more general way in > Camel? > Suppose you do not use Jetty as the starting consumer? > > It can't obviously be done for all components and it's really a case by case scenario. But it can be done very easily for jms and it can be done using jetty continuations using http. Having only those 2 components, which represent the two most widely used transports would be enough as a start imho. But the real problem does not come from the components, but rather from camel internals that don't support that. The completion / unitofWork is not sufficient. It can carry the callback if needed, but the pipeline has to know whether there will be a response or not. That is what was done in the pipeline in 1.x. See http://svn.apache.org/repos/asf/camel/tags/camel-1.6.2/camel-core/src/main/java/org/apache/camel/processor/Pipeline.java You'll see depending on whether the processor has finished is work synchronously or if it has not finished yet, the code need to follow two different paths. What we really need is this internal machinery. The transport are the easy part really. > > > > > > > >> > >> > >> > >> > > >> >> > >> >> > >> >> > -- > >> >> > 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 > >> > > >> > >> > >> > >> -- > >> 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 > > > > > > -- > 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
