----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> 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
