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 Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
