I'm attaching a version of CommonsHTTPSender that works "out-of-the box" with axis 1.1RC1 and the latest version of commons-httpclient. Basically you need to change the client-config.wsdd file to use CommonsHTTPSender instead of HTTPSender and the right thing will happen.
Some notes about this revision: 1. it does not (yet) set up the the configuration on the connection pool to anything other than the default for httpclient. In practice this means that you can only have 2 connections in the pool, per the HTTP RFC (see commons-httpclient for more on this). Clearly the right thing to do is to implement dims' suggested solution. Alan -- any interest in taking this on? 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. 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'. 4. There is a bug in commons-httpclient that causes it to fail when the client tries to chunk data *to* the server. I have therefore disabled upward chunking using the workaround that is suggested on the commons-httpclient bugzilla entry. This is commented in the source code for the invoke method. 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. 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. Eric -----Original Message----- From: Alan Moore [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 05, 2003 3:07 PM To: '[EMAIL PROTECTED]' Subject: RE: DO NOT REPLY [Bug 16522] - Allow Axis HTTP 1.1 clients to u se Keep-Alive Eric, I could *really* use this feature so if you need help getting it working let me know and I'll be glad to help code and/or test. alan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 05, 2003 1:59 PM To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 16522] - Allow Axis HTTP 1.1 clients to use Keep-Alive DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16522>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16522 Allow Axis HTTP 1.1 clients to use Keep-Alive ------- Additional Comments From [EMAIL PROTECTED] 2003-03-05 21:58 ------- Eric, Any patches to CommonsHTTPSender would be VERY welcome. You can extend the DefaultHTTPTransportClientProperties/TransportClientProperties model to support properties for the commons-httpclient pool config. Thanks, dims
CommonsHTTPSender.java
Description: Binary data
