axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: DO NOT REPLY [Bug 16522] - Allow Axis HTTP 1.1 clients to u se Keep-Alive
Date Thu, 06 Mar 2003 01:10:58 GMT

----- Original Message -----
From: <Eric.D.Friedman@WellsFargo.COM>
To: <>
Cc: <>
Sent: Wednesday, March 05, 2003 15:27
Subject: RE: DO NOT REPLY [Bug 16522] - Allow Axis HTTP 1.1 clients to u se

> 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
> 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
> of threads on an 8 CPU machine.  I even wrote a spoof http server to
> 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
> network, it seems).  I also ran it with Optimizeit and am confident that
> 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
> output stream, while httpclient wants to read the request body from an
> 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
> the MessageContext object.  The only state added to CommonsHTTPClient is
> 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
> Axis architecture and that it does a decent job of hiding the fact that
> commons-httpclient library is being used as the transport provider from
> 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.


View raw message