Mailing-List: contact httpcomponents-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <httpcomponents-dev@jakarta.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <45CB5068.305@dubioso.net>
Date: Thu, 08 Feb 2007 17:31:36 +0100
From: Roland Weber <http-async@dubioso.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.0.9) Gecko/20070102 SeaMonkey/1.0.7
MIME-Version: 1.0
To: HttpComponents Project <httpcomponents-dev@jakarta.apache.org>
Subject: Re: [jira] Commented: (HTTPCLIENT-258) RFE: Implement HTTP 1.1
 Pipelining
References: <14536403.1170705620125.JavaMail.jira@brutus>
 <45C9F90E.2060101@dubioso.net> <45C9FC62.6030304@odi.ch>
In-Reply-To: <45C9FC62.6030304@odi.ch>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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