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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
[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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
