Mailing-List: contact httpclient-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient User Discussion" <httpclient-user@jakarta.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <46169704.6020006@dubioso.net>
Date: Fri, 06 Apr 2007 20:52:52 +0200
From: Roland Weber <ossfwot@dubioso.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.1.2) Gecko/20070319 SeaMonkey/1.1.1
MIME-Version: 1.0
To: HttpClient User Discussion <httpclient-user@jakarta.apache.org>
Subject: Re: Question about MultiThreadedHttpConnectionManager
References: <CEB95FDE3027B54481716F79E9CA785D3078EC@mssb01.stone-ware.com>
In-Reply-To: <CEB95FDE3027B54481716F79E9CA785D3078EC@mssb01.stone-ware.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi Tony,

> If my client opens a persistent HTTP 1.1 connection to the server and
> sends 4 requests and then sends the 5th request with a Connection: close
> header, all 5 of those requests are supposed to be sent over the same
> connection, right?

If your client is single-threaded and releases the connection each time
after processing the response and before sending the next request, yes.
In the absence of other threads, that is. However, it is a performance
optimization that the open connection is re-used. It does or rather
should not affect the correctness of the application. Servers should
not care whether requests come in over the same connection, or another
one.

> What is happening and what I was attempting to
> demonstrate in my primitive picture was the fact that the HttpClient at
> some point decides that it is going to start a new connection and splits
> those 5 requests across 2 connections.  In my application, the same
> thread is sending all 5 of those requests but I do have other threads
> sendings requests to the same host at that time.

All your threads share the same pool of connections. If the one
connection in your pool that is already open gets handed out to
a different thread, your first thread gets a new connection to
the same host. Works as designed.

> Once the load starts
> to increase, the MTHCM starts opening more connections as it should but
> those connections start getting crossed up more as things go on.

MTHCM _should_ open as many connections as allowed by the
"connections per host" limit, which by default is set to 2.
If it opens more, please file a bug report. A test case that
exhibits the problem would be welcome.

> But, I have seen WebDAV requests that are
> expecting all 5 of those requests to come through on the same connection
> blow chunks because the HttpClient is breaking protocol.

HttpClient implements the HTTP protocol, not WebDAV. If WebDAV has
additional constraints that need to be enforced, you should use a
WebDAV client implementation. If your WebDAV server expects all
requests over a single connection although that is not specified
by WebDAV (it sure isn't by HTTP), the server is buggy. Either way,
it is not HttpClient that is "breaking protocol".

To work around this problem will be tricky, since the connection
and connection manager classes are closely tied to eachother in 3.x.
The Slide project has a WebDAV client implementation:
http://jakarta.apache.org/slide/index.html

> I am not keeping state in the server since it is really just a
> transparent proxy so client state is maintained in the originating
> client.

Make sure that the backend server does not send cookies.
Because if it does, you are keeping state without knowing it.

cheers,
  Roland


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