hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Pipelining capable 4.2 HttpClient
Date Wed, 05 Dec 2012 18:15:23 GMT
On Tue, 2012-12-04 at 14:10 -0800, Jonathan Booth wrote:
> On Dec 4, 2012, at 3:13 PM, Oleg Kalnichevski wrote:
> > I believe you are on the right track. You'll definitely need a pipeline
> > capable version of HttpAsyncRequestExecutor and most likely a custom
> > HttpAsyncRequestExecutionHandler (or similar interface optimized for
> > pipelining) as well.
> So I made a version of that and of HttpAsyncRequester (since that's what creates HttpAsyncRequestExecutionHandler
objects). I've instrumented my code with some logging and I can see my code being called,
but I'm missing some sort of trigger back to say "request has been sent, I'm ready to send
the next request" out of HttpAsyncRequestExecutor.
> At least that's what my logs suggest. I see requestReady -> outputReady -> requestReady
(early return), but then it stalls until the remote server (a dummy server with a long response
delay) responds. Only once the response goes through and processRequest is called will the
next requestReady->output->request sequence start playing.
> But now I think I may have found the problem -- I think it's that our client code is
using a connection pool, so that's allocating that connection out of the pool to the first
request and then the second can't pick it up, despite going to the same target host. I guess
I'll have to override the pool too, to handle pipeline requests and return a previously leased
connection if it is to the same target host.

Hi Jonathan

Connection management has be implemented entirely differently by a
pipelining capable client side HTTP protocol handler. It needs to hold
onto the connection as long as there are messages in the pipeline,
unlike the default implementation that releases connection back to the
pool as soon as one HTTP exchange is done.

Hope this helps


To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message