You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Oleg Kalnichevski (JIRA)" <ji...@apache.org> on 2007/02/05 21:00:20 UTC
[jira] Commented: (HTTPCLIENT-258) RFE: Implement HTTP 1.1
Pipelining
[ https://issues.apache.org/jira/browse/HTTPCLIENT-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470333 ]
Oleg Kalnichevski commented on HTTPCLIENT-258:
----------------------------------------------
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
Oleg
> RFE: Implement HTTP 1.1 Pipelining
> ----------------------------------
>
> Key: HTTPCLIENT-258
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-258
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Affects Versions: 2.0 Beta 2
> Environment: Operating System: All
> Platform: All
> Reporter: Ortwin Glück
> Priority: Minor
> Fix For: 5.0
>
>
> Pipelining is currently employed by Mozilla based browsers, which are reported
> to gain some performance from it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [jira] Commented: (HTTPCLIENT-258) RFE: Implement HTTP 1.1
Pipelining
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2007-02-08 at 20:07 +0100, Roland Weber wrote:
> Hi Oleg,
>
> > My position remains the same. Let us start _somewhere_ and get something
> > that actually _works_. Once we have _something_ working, it is easier to
> > observe commonalities in code and move components to a better home.
>
> No objections. But as I said before: when alpha 4 is out, we should discuss
> scope and location. I feel that NIO has outgrown HttpCore considerably.
>
> > I am open to having HttpConn NIO at some point, but
> > respectfully remain skeptical about the possibility of HttpConn being a
> > unifying API for both blocking and non-blocking connection management.
>
> I was not going so far as to think there would be a unifying API.
> I'm dreaming of a similar split of concerns between BIO and NIO,
> with HttpConn-NIO being a module that makes use of only some of the
> classes and interfaces in HttpConn. For example the representation
> of routes, currently provided by HostConfiguration.
Hi Roland,
I am perfectly fine with having NIO extensions for HttpConn.
Oleg
>
> > I do not want to steer you in any particular direction, but personally
> > tend to think of HttpAsync as HttpClient on top of HttpCore NIO. I would
> > very much welcome HttpAsync dropping blocking I/O stuff altogether and
> > concentrating on the non-blocking I/O model, which seems to fit better
> > its stated goals.
>
> If we can figure out how to map the route building stuff (connect,
> tunnel, layer SSL) to NIO, I can see that happening. But there's a
> long way to go yet.
>
> cheers,
> Roland
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [jira] Commented: (HTTPCLIENT-258) RFE: Implement HTTP 1.1 Pipelining
Posted by Roland Weber <ht...@dubioso.net>.
Hi Oleg,
> My position remains the same. Let us start _somewhere_ and get something
> that actually _works_. Once we have _something_ working, it is easier to
> observe commonalities in code and move components to a better home.
No objections. But as I said before: when alpha 4 is out, we should discuss
scope and location. I feel that NIO has outgrown HttpCore considerably.
> I am open to having HttpConn NIO at some point, but
> respectfully remain skeptical about the possibility of HttpConn being a
> unifying API for both blocking and non-blocking connection management.
I was not going so far as to think there would be a unifying API.
I'm dreaming of a similar split of concerns between BIO and NIO,
with HttpConn-NIO being a module that makes use of only some of the
classes and interfaces in HttpConn. For example the representation
of routes, currently provided by HostConfiguration.
> I do not want to steer you in any particular direction, but personally
> tend to think of HttpAsync as HttpClient on top of HttpCore NIO. I would
> very much welcome HttpAsync dropping blocking I/O stuff altogether and
> concentrating on the non-blocking I/O model, which seems to fit better
> its stated goals.
If we can figure out how to map the route building stuff (connect,
tunnel, layer SSL) to NIO, I can see that happening. But there's a
long way to go yet.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [jira] Commented: (HTTPCLIENT-258) RFE: Implement HTTP 1.1
Pipelining
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2007-02-08 at 18:30 +0100, Roland Weber wrote:
> Hi Oleg,
>
> > I still do not see how HttpCore NIO attempts to subsume the
> > responsibilities of HttpConn and HttpAsync since both modules are
> > currently based on blocking I/O model.
>
> Maybe I did not find the appropriate words. I was talking about
> abstract responsibilities, not about implementation techniques.
> Since we've thrown Connection.open() out of HttpCore, I see the
> abstract responsibilities of HttpConn as:
> - open connections
> - tunnel/layer SSL
> - manage connections for re-use
> - enforce connection limits
> Currently there are only blocking interfaces and implementations
> (if any), which doesn't mean we couldn't put NIO interfaces and
> implementations for these _responsibilites_ there as well. If we
> would find an elegant way of separating NIO-core from NIO-conn
> functionality.
> We never discussed the exact scope of HttpAsync, and I kept on
> emphasizing that the _initial_ implementations would be based
> on blocking IO, because I don't know how to implement others.
> That doesn't mean there should not be non-blocking dispatchers.
> There should be. I just can't implement them, in particular not
> until I've figured out much more about the dispatching problem.
> The dispatching is what I consider the focus of HttpAsync in it's
> present form, with some background worker thread stuff thrown in
> as an implementation detail, because I'd need those to make it
> work with blocking IO.
> To me, it looks as if we're making a very nice split of responsi-
> bilites into Core, Conn, and others for the blocking implementation,
> while the NIO implementation just pushes everything into one module.
> The part that concerns me most about this is that the NIO module
> is in HttpCore. So we have a module HttpCore-main which can do
> very little without other modules, and a module HttpCore-NIO that
> does almost everything by itself.
Roland,
My position remains the same. Let us start _somewhere_ and get something
that actually _works_. Once we have _something_ working, it is easier to
observe commonalities in code and move components to a better home.
I have worked extensively with both models and am very skeptical we can
have a connection management abstraction that works reasonably well with
both blocking and non-blocking I/O. NIO implies a totally different way
of thinking, which does not mix well with APIs built around the classic
I/O model. I am open to having HttpConn NIO at some point, but
respectfully remain skeptical about the possibility of HttpConn being a
unifying API for both blocking and non-blocking connection management.
>
> > Yes, one can use NIO to access file system objects but currently all
> > file system bound operations are _blocking_.
>
> Oh I see. Blocking non-blocking. A fake.
>
> > This is my personal vision of the HttpComponents stacks:
> >
> > (1) Blocking HTTP (mainstream)
> > HttpClient
> > HttpConn, HttpCookie, HttpAuth
> > HttpCore
> >
> > (2) Non-blocking HTTP (covers special use cases)
> > HttpAsync, HttpCookie, HttpAuth
> > HttpCore-NIO
> > HttpCore
>
> A traditional IO implementation of HttpAsync will make use of HttpConn.
> Probably not the connection managers there, but the connection
> interfaces and implementations, operators, and the auto-close logic.
> I'd also try to re-use the Http[Method]Director logic from HttpClient.
> A NIO implementation of HttpAsync might look much like current HttpNIO
> at the backend, while adding the auto-close logic, Http[Method]Director
> and application notification callbacks at the frontend.
>
I do not want to steer you in any particular direction, but personally
tend to think of HttpAsync as HttpClient on top of HttpCore NIO. I would
very much welcome HttpAsync dropping blocking I/O stuff altogether and
concentrating on the non-blocking I/O model, which seems to fit better
its stated goals.
Cheers,
Oleg
>
>
> cheers,
> Roland
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [jira] Commented: (HTTPCLIENT-258) RFE: Implement HTTP 1.1 Pipelining
Posted by Roland Weber <ht...@dubioso.net>.
Hi Oleg,
> I still do not see how HttpCore NIO attempts to subsume the
> responsibilities of HttpConn and HttpAsync since both modules are
> currently based on blocking I/O model.
Maybe I did not find the appropriate words. I was talking about
abstract responsibilities, not about implementation techniques.
Since we've thrown Connection.open() out of HttpCore, I see the
abstract responsibilities of HttpConn as:
- open connections
- tunnel/layer SSL
- manage connections for re-use
- enforce connection limits
Currently there are only blocking interfaces and implementations
(if any), which doesn't mean we couldn't put NIO interfaces and
implementations for these _responsibilites_ there as well. If we
would find an elegant way of separating NIO-core from NIO-conn
functionality.
We never discussed the exact scope of HttpAsync, and I kept on
emphasizing that the _initial_ implementations would be based
on blocking IO, because I don't know how to implement others.
That doesn't mean there should not be non-blocking dispatchers.
There should be. I just can't implement them, in particular not
until I've figured out much more about the dispatching problem.
The dispatching is what I consider the focus of HttpAsync in it's
present form, with some background worker thread stuff thrown in
as an implementation detail, because I'd need those to make it
work with blocking IO.
To me, it looks as if we're making a very nice split of responsi-
bilites into Core, Conn, and others for the blocking implementation,
while the NIO implementation just pushes everything into one module.
The part that concerns me most about this is that the NIO module
is in HttpCore. So we have a module HttpCore-main which can do
very little without other modules, and a module HttpCore-NIO that
does almost everything by itself.
> Yes, one can use NIO to access file system objects but currently all
> file system bound operations are _blocking_.
Oh I see. Blocking non-blocking. A fake.
> This is my personal vision of the HttpComponents stacks:
>
> (1) Blocking HTTP (mainstream)
> HttpClient
> HttpConn, HttpCookie, HttpAuth
> HttpCore
>
> (2) Non-blocking HTTP (covers special use cases)
> HttpAsync, HttpCookie, HttpAuth
> HttpCore-NIO
> HttpCore
A traditional IO implementation of HttpAsync will make use of HttpConn.
Probably not the connection managers there, but the connection
interfaces and implementations, operators, and the auto-close logic.
I'd also try to re-use the Http[Method]Director logic from HttpClient.
A NIO implementation of HttpAsync might look much like current HttpNIO
at the backend, while adding the auto-close logic, Http[Method]Director
and application notification callbacks at the frontend.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [jira] Commented: (HTTPCLIENT-258) RFE: Implement HTTP 1.1
Pipelining
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2007-02-08 at 16:56 +0100, Roland Weber wrote:
> Hi Oleg,
>
> >> 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 come?
>
> HttpConn: It establishes connections, doesn't it?
> HttpAsync: If you add the queueing.
>
Hi Roland,
I still do not see how HttpCore NIO attempts to subsume the
responsibilities of HttpConn and HttpAsync since both modules are
currently based on blocking I/O model.
> > Oh my god! C'mon, Roland. Do you know how much of my time and hard work
> > I put into HttpClient 3 is going to get thrown into the rubbish bin?
>
> I grant you that :-( On the positive side, consider how many people
> will keep using HC 3.x for years to come and refuse to switch to 4...
>
> > I said this before, I'll say it again: NIO makes no frigging sense for
> > pure clients or pure servers. The complexity of NIO is simply not worth
> > it. Blocking HTTP with a reasonable threading strategy will always
> > outperform non-blocking one at a fraction of complexity of the latter.
>
> Well, then let me rephrase the suggestion without the frustration:
> HttpClient has become an interface, and we can have different
> implementations. If much of the functionality is already there
> in NIO, we have the option of implementing HttpClient on top of that.
> The user won't see anything of the complexity. If it allows us to
> come out with a first implementation sooner, it could be worth a shot.
>
I am not sure I like the idea of HttpClient being an interface. I also
do not see a point in developing a NIO based equivalent of HttpClient
3.x. It should be possible to easily assemble one using HttpCore NIO,
HttpCookie and HttpAuth, if one feels like doing so, but as I said
before, I see no benefits in NIO of what so ever for pure HTTP clients.
> > NIO makes sense for middle-tier services like message mediators and
> > reverse proxies.
>
> Because they are routing through incoming messages and don't
> have to deal with user authentication and such things? Because
> they don't call blocking front-end and back-end services?
> I don't know enough of NIO to understand the tradeoff. A simple
> file server can access the file system through NIO, too.
Yes, one can use NIO to access file system objects but currently all
file system bound operations are _blocking_.
This is my personal vision of the HttpComponents stacks:
(1) Blocking HTTP (mainstream)
HttpClient
HttpConn, HttpCookie, HttpAuth
HttpCore
(2) Non-blocking HTTP (covers special use cases)
HttpAsync, HttpCookie, HttpAuth
HttpCore-NIO
HttpCore
I want to re-iterate: it is just my personal vision. I am very open to
alternative views.
Oleg
>
> cheers,
> Roland
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [jira] Commented: (HTTPCLIENT-258) RFE: Implement HTTP 1.1 Pipelining
Posted by Roland Weber <ht...@dubioso.net>.
Hi Oleg,
>> 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 come?
HttpConn: It establishes connections, doesn't it?
HttpAsync: If you add the queueing.
> Oh my god! C'mon, Roland. Do you know how much of my time and hard work
> I put into HttpClient 3 is going to get thrown into the rubbish bin?
I grant you that :-( On the positive side, consider how many people
will keep using HC 3.x for years to come and refuse to switch to 4...
> I said this before, I'll say it again: NIO makes no frigging sense for
> pure clients or pure servers. The complexity of NIO is simply not worth
> it. Blocking HTTP with a reasonable threading strategy will always
> outperform non-blocking one at a fraction of complexity of the latter.
Well, then let me rephrase the suggestion without the frustration:
HttpClient has become an interface, and we can have different
implementations. If much of the functionality is already there
in NIO, we have the option of implementing HttpClient on top of that.
The user won't see anything of the complexity. If it allows us to
come out with a first implementation sooner, it could be worth a shot.
> NIO makes sense for middle-tier services like message mediators and
> reverse proxies.
Because they are routing through incoming messages and don't
have to deal with user authentication and such things? Because
they don't call blocking front-end and back-end services?
I don't know enough of NIO to understand the tradeoff. A simple
file server can access the file system through NIO, too.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [jira] Commented: (HTTPCLIENT-258) RFE: Implement HTTP 1.1
Pipelining
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2007-02-07 at 17:06 +0100, Roland Weber wrote:
> 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 come?
> 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.
Oh my god! C'mon, Roland. Do you know how much of my time and hard work
I put into HttpClient 3 is going to get thrown into the rubbish bin?
I said this before, I'll say it again: NIO makes no frigging sense for
pure clients or pure servers. The complexity of NIO is simply not worth
it. Blocking HTTP with a reasonable threading strategy will always
outperform non-blocking one at a fraction of complexity of the latter.
NIO makes sense for middle-tier services like message mediators and
reverse proxies.
Oleg
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [jira] Commented: (HTTPCLIENT-258) RFE: Implement HTTP 1.1 Pipelining
Posted by Roland Weber <ht...@dubioso.net>.
Hi Odi,
> For the sake of transaction safety it is important that:
>
> a) the implementation does not alter the order of the requests within
> the pipeline, and
Requests in the pipeline can not be reordered. HTTP doesn't allow
for it. Responses will arrive in exactly the same order as the
requests were sent into the pipeline. I was discussing the options
for picking up requests before putting them into a pipeline.
> b) that all request within a pipeline go over the same physical
> connection (that is the definition of pipelining).
Exactly.
> Just imagine a scenario of asynchronous Webservice calls that create,
> modify and finally delete a remote object. The order of those operations
> is important. And the operations can not be executed in parallel. So we
> must provide an API that guarantees that.
I don't see that. Current non-pipelining operation doesn't guarantee
order of requests either. If three requests are sent to a host, they
can go over three different simultaneous connections and be served on
the remote side in random order. If the sequence of requests is relevant,
the application has to serialise them appropriately.
Even if the server picks up requests in the order in which the connections
are established, our retry handling is enough to mess things up. If the
initial connection attempt for the first request fails and is retried,
the connection for the second request can already have been established.
HttpClient provides a transport layer for HTTP messages and does at
this time not make any guarantees about the order of requests that are
issued simultaneously. If an application operates asynchronously, that
is if it has multiple threads to create and send requests, it is still
the application's responsibility to serialise where necessary. Having
a pipelining implementation of HttpClient wouldn't change that.
In the HttpDispatcher interface, I have explicitly mentioned the
potential out-of-order execution in the JavaDocs from the very first
draft. Only the "Simple" implementation would be able to guarantee
request order. It might be worth to have a "Simple" implementation
that occasionally does not pick the first request, just to make sure
that nobody relies on such behavior.
RFC 2616 mentions the following in section 8.1.2.2:
Clients SHOULD NOT pipeline requests using non-idempotent methods or
non-idempotent sequences of methods (see section 9.1.2). Otherwise, a
premature termination of the transport connection could lead to
indeterminate results. A client wishing to send a non-idempotent
request SHOULD wait to send that request until it has received the
response status for the previous request.
Since HttpClient can't tell which requests are idempotent or in
a particular sequence, I see this as an application responsibility.
> For transactionally safe systems it is of course dangerous to use
> pipelining with non-idempotent operations. Because when the connection
> breaks before all outstanding responses are received, the client does
> not know if the server has received the requests. The problem is
> actually also present without pipelining, but pipelining makes the
> situation much more probable.
I always assumed that a server would not pick up a request for
processing until the response for the previous one has been sent.
But there's actually nothing in RFC 2616 that mandates this kind
of behavior. Thanks for bringing this to my attention.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [jira] Commented: (HTTPCLIENT-258) RFE: Implement HTTP 1.1 Pipelining
Posted by Ortwin Glück <od...@odi.ch>.
Roland,
For the sake of transaction safety it is important that:
a) the implementation does not alter the order of the requests within
the pipeline, and
b) that all request within a pipeline go over the same physical
connection (that is the definition of pipelining).
Just imagine a scenario of asynchronous Webservice calls that create,
modify and finally delete a remote object. The order of those operations
is important. And the operations can not be executed in parallel. So we
must provide an API that guarantees that.
For transactionally safe systems it is of course dangerous to use
pipelining with non-idempotent operations. Because when the connection
breaks before all outstanding responses are received, the client does
not know if the server has received the requests. The problem is
actually also present without pipelining, but pipelining makes the
situation much more probable.
Ortwin
Roland Weber wrote:
> 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
>
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [jira] Commented: (HTTPCLIENT-258) RFE: Implement HTTP 1.1 Pipelining
Posted by Roland Weber <ht...@dubioso.net>.
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