You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Er...@WellsFargo.COM on 2003/03/06 18:02:09 UTC

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

OK, I'm glad you caught it!

-----Original Message-----
From: Davanum Srinivas [mailto:dims@yahoo.com]
Sent: Thursday, March 06, 2003 6:52 AM
To: axis-dev@ws.apache.org
Cc: Eric.D.Friedman@WellsFargo.COM
Subject: RE: DO NOT REPLY [Bug 16522] - Allow Axis HTTP 1.1 clients to u
se Keep-Alive


Eric,

Forcing the ByteArrayOutputStream into a String was a bad idea....DIME
croaks. See latest cvs, am
constructing a ByteArrayInputStream to hold the request body.

Thanks,
dims

--- Eric.D.Friedman@WellsFargo.COM wrote:
> 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:amoore@ciphergen.com]
> Sent: Wednesday, March 05, 2003 3:07 PM
> To: 'axis-dev@ws.apache.org'
> 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: bugzilla@apache.org [mailto:bugzilla@apache.org]
> Sent: Wednesday, March 05, 2003 1:59 PM
> To: axis-dev@ws.apache.org
> 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 dims@yahoo.com  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
> 
> 

> ATTACHMENT part 2 application/octet-stream name=CommonsHTTPSender.java



=====
Davanum Srinivas - http://webservices.apache.org/~dims/

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/