You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Jonathan Booth <jb...@yahoo-inc.com> on 2012/12/04 20:32:08 UTC

Pipelining capable 4.2 HttpClient

Hi all,

I'm continuing the apparently elusive quest to get a pipelining capable client. We're using the 4.2 HttpCore-NIO parts to build one. I'm aware of the issues with non-idempotent POST/PUT requests, as well as expect: 100-continue forcing a pipeline flush. We still need pipelining for our use case (high bandwidth message rate of small messages over long-latency links with idempotent PUT transfers). I found the previous mails on this list talking about do this in the AsyncNHttpClientHandler, which is now deprecated in 4.2.

It looks like I just need to modify HttpAsyncRequestExecutor to have a queue of states so it can track the messages that are in-flight but not yet replied to. It seems like it should work, but a first pass at it doesn't actually do pipelining. I am getting a feeling I also need to extend/replace HttpAsyncRequester and BasicAsyncRequestExecutionHandler in order to have a version of the handler where I can close the requestProducer and responseConsumer independently (producer once I move to MessageState.COMPLETED for that request, and consumer once we get a reply back).

Can anyone comment if I'm on the right track, or off in the weeds?

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

Re: Pipelining capable 4.2 HttpClient

Posted by Oleg Kalnichevski <ol...@apache.org>.
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

Re: Pipelining capable 4.2 HttpClient

Posted by Jonathan Booth <jb...@yahoo-inc.com>.
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

Re: Pipelining capable 4.2 HttpClient

Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2012-12-04 at 11:32 -0800, Jonathan Booth wrote:
> Hi all,
> 
> I'm continuing the apparently elusive quest to get a pipelining capable client. We're using the 4.2 HttpCore-NIO parts to build one. I'm aware of the issues with non-idempotent POST/PUT requests, as well as expect: 100-continue forcing a pipeline flush. We still need pipelining for our use case (high bandwidth message rate of small messages over long-latency links with idempotent PUT transfers). I found the previous mails on this list talking about do this in the AsyncNHttpClientHandler, which is now deprecated in 4.2.
> 
> It looks like I just need to modify HttpAsyncRequestExecutor to have a queue of states so it can track the messages that are in-flight but not yet replied to. It seems like it should work, but a first pass at it doesn't actually do pipelining. I am getting a feeling I also need to extend/replace HttpAsyncRequester and BasicAsyncRequestExecutionHandler in order to have a version of the handler where I can close the requestProducer and responseConsumer independently (producer once I move to MessageState.COMPLETED for that request, and consumer once we get a reply back).
> 
> Can anyone comment if I'm on the right track, or off in the weeds?
> 

Hi Jonathan

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.

I was planning to work on adding support for message pipelining to
HttpCore but it looks like I will not get around to until HttpClient
(blocking) 4.3 is released.

Cheers

Oleg 


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