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