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 00:27:36 UTC
RE: DO NOT REPLY [Bug 16522] - Allow Axis HTTP 1.1 clients to u
se Keep-Alive
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
Re: DO NOT REPLY [Bug 16522] - Allow Axis HTTP 1.1 clients to u se Keep-Alive
Posted by 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
RE: DO NOT REPLY [Bug 16522] - Allow Axis HTTP 1.1 clients to u se Keep-Alive
Posted by Davanum Srinivas <di...@yahoo.com>.
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/