hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <http-as...@dubioso.net>
Subject Re: [jira] Commented: (HTTPCLIENT-258) RFE: Implement HTTP 1.1 Pipelining
Date Wed, 07 Feb 2007 16:06:38 GMT
Hi Oleg,

> Actually, HttpCore NIO is fully HTTP pipelining capable.
> I just need to add ability to queue requests / responses
> to the default protocol handlers. So, we'll have a full-blown
> HTTP pipelining support in HttpCore 4.0

I may be wrong, but I tend to think that it takes a little more
than just a queue or two. If you have a pipeline open, you want
to pick a request that can be sent through that pipe rather than
the first in the queue. If you're going to open a new connection,
you want to skip requests that fit into an open pipeline, at least
if the connections-per-host limit is exceeded. Of course with
safeguards that prevent requests from starving. There's pipelines
that are open, such that are closed for writing (after a request
with connection: close or HTTP/1.0 without content length), and
such that are temporarily closed for writing (waiting for a 100
continue response). Then you should have handling for re-sending
requests if a pipeline is terminated prematurely (after a response
with connection: close).
All those are things that an HttpDispatcher was supposed to take
care of. HttpCore-NIO (emphasis on _core_) already subsumes
responsibilities of HttpConn, now HttpAsync is to follow. How
much more do you want to squeeze into it?

On a related matter, I'm getting a little frustrated here. I've
invested considerable time first into HttpAsync and more recently
into HttpConn, coming from a blocking IO perspective. If the
responsibilities of these two components are so easily addressed
by adding just a little here and there in Http-NIO, then let's
send HttpConn the same way that HttpAsync has already gone and
put HttpClient directly on top of NIO.
I'm not going to spend my time on implementing very tricky and
mostly redundant functionality for a measly 10% performance
advantage that blocking IO may have over NIO. I can happily
write user documentation and leave the NIO coding to you.

When HttpCore alpha4 is out, we should reassess the scope,
location and roadmap for our components and modules.

cheers,
  Roland



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


Mime
View raw message