Re: DO NOT REPLY [Bug 16522] - Allow Axis HTTP 1.1 clients to u se Keep-Alive

[Steve Loughran <st...@iseran.com>]

----- Original Message -----
From: <Er...@WellsFargo.COM>
To: <ax...@ws.apache.org>
Cc: <am...@ciphergen.com>
Sent: Wednesday, March 05, 2003 15:27
Subject: RE: DO NOT REPLY [Bug 16522] - Allow Axis HTTP 1.1 clients to u se
Keep-Alive

> 2. My fix also quietly fixes bug # 17539, but not in exactly the same way
> that dims fixed it when I reported it earlier (I've been hanging back on
> RC1, don't have "real" access to CVS at the office, <insert other lame
> excuses>).  This is probably not a huge issue, but forewarned is
forearmed,
> etc. etc.

you know, keep fixing bugs and adding features and you become a committer,
at which point CVS access becomes possible over socks and ssh, if that works
for you :)

>
> 3. I have tested this code pretty extensively with a small and large
number
> of threads on an 8 CPU machine.  I even wrote a spoof http server to
verify
> that the connections are getting reusued from the server's perspective (I
> needed to do this because I'm doing a bunch of network performance tuning
> work and the results were rather strange, an artifact of our lousy
internal
> network, it seems).  I also ran it with Optimizeit and am confident that
the
> right number of instances is being created.  I even managed to cause
> intermittent network failures and observed that although an individual
> request would trigger an axis fault, the other requests in my app would
> safely acquire a new connection and keep on chuggin'.

that's good. Its hard to test this kind of stuff in junit, but 8-way cpus
are good for thread safety tests.

>
> 5. One weakness of hooking up httpclient and axis is that their I/O layers
> are not entirely compatible.  That is, axis wants to write its message on
an
> output stream, while httpclient wants to read the request body from an
input
> stream.  The solution, such as it is, is to buffer the data in
> CommonsHTTPSender.  This would be bad if you're sending SOAP messages with
> enormous attachments.

I suppose there is a two-thread queue bridge thing we could do there

>
> The strategy I took was this:  all state (cookies, and the like) remains
in
> the MessageContext object.  The only state added to CommonsHTTPClient is
the
> MultiThreadedHttpConnectionManager instance.  This means that the actual
> HttpClient instances are themselves discarded between requests, with any
> session information transferred to/from the MessageContext objects at the
> end/beginning of the invocation.  I believe that this is consistent with
the
> Axis architecture and that it does a decent job of hiding the fact that
the
> commons-httpclient library is being used as the transport provider from
the
> rest of the framework.

I think this is a good approach, and once Axis1.1 is out the door, this is
one of the features that should go in to Axis1.2, especially now that the
commons http libraries are seemingly stabilizing.

-steve