You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Norris Merritt <no...@peregrine.com> on 2003/01/28 20:03:56 UTC
RE: Keep-alive SOAP connections are disabled in Axis; Axis hangs
if they are enabled
I just tried them, and Chen's HTTPSender and HTTPInputStream work great, for
both http and https. The only issues I encountered were that when you
download the attachments from the mailing list, they have funky MIME
characters in them like =0A= and =3D that have to be converted. Also, Axis
has changed a bit since 4/2002 so there were very minor tweaks required (for
example, clearProperty has become removeProperty, etc). Here are the updated
files. Forgive me for making the braces line up :-)
-----Original Message-----
From: billa@effectnet.com [mailto:billa@effectnet.com]
Sent: Tuesday, January 28, 2003 9:54 AM
To: norris.merritt@peregrine.com
Subject: Re: Keep-alive SOAP connections are disabled in Axis; Axis
hangs if they are enabled
Norris
Thanks much for your reply and great analysis. I also would have thought
that it is a much bigger issue than the responses seem to indicate.
Bill
billa@effectnet.com
> Anyone care to comment on this, or the code submission from Shih-Chang
> Chen of 4/9/2002 to fix it:
> http://marc.theaimsgroup.com/?l=axis-dev&m=101837980122603&w=2
>
> Here is what I have found so far in looking into this, from the
> perspective of using Axis as a client:
>
> 1) org.apache.axis.transport.http.HTTPSender.java deliberately generates
> a Connection:close header even if HTTP 1.1 is set, which prevents
> connections from being maintained. A comment in the code implies this is
> deliberate, perhaps to fix the hang I discovered (described below).
> Commenting out the line 334 eliminates the Connection:close.
>
> 2) HTTPSender.java calls getSocket() for every transaction, which
> creates a new SocketFactory for every transaction, which in turn create
> a new socket for each transaction. Obviously this needs to change if
> connections are to be maintained across calls. This is simple to do.
>
> 3) If you modify HttpSender.java to correct the above 2 problems, and
> begin an HTTP 1.1 session with a non-Axis SOAP server which supports
> Keep-Alive, the result is a hang in the Axis client during receipt of
> the first response, caused by Xerces trying to read more bytes than are
> available from the SocketInputStream it is given as it's input source.
> Axis clients seem to depend on the other server closing the connection
> to prevent this hang. Although Axis is careful to read exactly the right
> number of bytes from the input stream when consuming the headers, and is
> careful to construct an inputstream for Xerces that is set up such that
> the bytes available exactly equal the Content-Length, Xerces still tries
> to read more from the input source, even if it should have seen a
> complete XML document by the time it has processed the bytes available.
> In other words, an Axis client would hang, with Xerces trying to read
> more than Content-Length bytes from the inputstream, if the the other
> side did not close the connection after sending its response.
>
> 4) You can make a temporary fix for the hang by supplying a read method
> in org.apache.axis.transport.http.SocketInputStream.java which checks
> in.available() before reading from the inputstream, and just reflects
> EOF to Xerces by returning -1 if in.available()==0. Then hang goes
> away, but the Socket gets closed when the InputStream gets closed. If
> you modify the close() code in
> org.apache.axis.transport.http.SocketInputStream to deliberately not
> close the Socket, then you can successfully maintain an HTTP 1.1
> connection with a non-Axis SOAP server across any number of SOAP calls.
>
> The changes in 4) are admittedly a hack, so I next plan to investigate
> the proposal from Shih-Chang Chen of 4/9/2002 which contains a
> replacement for HTTPpSender.java and an associated HTTPInputStream.java.
> This seems like the right way to go. I'm puzzled as to why this
> submission (and other posts about Keep-Alive) seem to have been ignored.
> Keep-Alive seems to be worthwhile, especially when SSL is used.
> -----Original Message-----
> From: Stocker, Walter [mailto:Walter.Stocker@t-systems.com]
> Sent: Friday, January 17, 2003 12:51 AM
> To: axis-user@xml.apache.org
> Subject: AW: Keep-alive SSL Web Service connections
>
>
> Implement your own SSLSocketFactory with a Socket Pool. I don't
> know any other way around this.
>
> -----Ursprüngliche Nachricht-----
> Von: billa@effectnet.com [mailto:billa@effectnet.com]
> Gesendet: Donnerstag, 16. Januar 2003 19:16
> An: axis-user@xml.apache.org
> Betreff: Keep-alive SSL Web Service connections
>
>
>
> I am designing a web service based application the will require a
> work
> flow of web service calls. SSL will be used for transport security. I am
> concerned about the SSL handshake overhead if each of the web
> service calls use a new SSL connection. I would like reuse the SSL
> socket across several calls thus accruing the handshake overhead only
> once.
>
> The Axis JavaDoc indicate that the org.apache.axis.transport.http...
> invoke methods create a new socket. So it seems that the current
> implementation does not support using a single HTTP socket across
> several web service calls.
>
> Is there a workaround?
>
> Thanks
> Bill Andrews
> billa@effectnet.com
RE: Keep-alive SOAP connections are disabled in Axis; Axis hangs if they are enabled
Posted by Davanum Srinivas <di...@yahoo.com>.
Norris,
Can you please submit a patch to Bugzilla?
(http://nagoya.apache.org/wiki/apachewiki.cgi?SubmitPatches)
Thanks,
dims
--- Norris Merritt <no...@peregrine.com> wrote:
> I just tried them, and Chen's HTTPSender and HTTPInputStream work great, for
> both http and https. The only issues I encountered were that when you
> download the attachments from the mailing list, they have funky MIME
> characters in them like =0A= and =3D that have to be converted. Also, Axis
> has changed a bit since 4/2002 so there were very minor tweaks required (for
> example, clearProperty has become removeProperty, etc). Here are the updated
> files. Forgive me for making the braces line up :-)
> -----Original Message-----
> From: billa@effectnet.com [mailto:billa@effectnet.com]
> Sent: Tuesday, January 28, 2003 9:54 AM
> To: norris.merritt@peregrine.com
> Subject: Re: Keep-alive SOAP connections are disabled in Axis; Axis
> hangs if they are enabled
>
>
>
> Norris
> Thanks much for your reply and great analysis. I also would have thought
> that it is a much bigger issue than the responses seem to indicate.
>
> Bill
> billa@effectnet.com
>
>
> > Anyone care to comment on this, or the code submission from Shih-Chang
> > Chen of 4/9/2002 to fix it:
> > http://marc.theaimsgroup.com/?l=axis-dev&m=101837980122603&w=2
> >
> > Here is what I have found so far in looking into this, from the
> > perspective of using Axis as a client:
> >
> > 1) org.apache.axis.transport.http.HTTPSender.java deliberately generates
> > a Connection:close header even if HTTP 1.1 is set, which prevents
> > connections from being maintained. A comment in the code implies this is
> > deliberate, perhaps to fix the hang I discovered (described below).
> > Commenting out the line 334 eliminates the Connection:close.
> >
> > 2) HTTPSender.java calls getSocket() for every transaction, which
> > creates a new SocketFactory for every transaction, which in turn create
> > a new socket for each transaction. Obviously this needs to change if
> > connections are to be maintained across calls. This is simple to do.
> >
> > 3) If you modify HttpSender.java to correct the above 2 problems, and
> > begin an HTTP 1.1 session with a non-Axis SOAP server which supports
> > Keep-Alive, the result is a hang in the Axis client during receipt of
> > the first response, caused by Xerces trying to read more bytes than are
> > available from the SocketInputStream it is given as it's input source.
> > Axis clients seem to depend on the other server closing the connection
> > to prevent this hang. Although Axis is careful to read exactly the right
> > number of bytes from the input stream when consuming the headers, and is
> > careful to construct an inputstream for Xerces that is set up such that
> > the bytes available exactly equal the Content-Length, Xerces still tries
> > to read more from the input source, even if it should have seen a
> > complete XML document by the time it has processed the bytes available.
> > In other words, an Axis client would hang, with Xerces trying to read
> > more than Content-Length bytes from the inputstream, if the the other
> > side did not close the connection after sending its response.
> >
> > 4) You can make a temporary fix for the hang by supplying a read method
> > in org.apache.axis.transport.http.SocketInputStream.java which checks
> > in.available() before reading from the inputstream, and just reflects
> > EOF to Xerces by returning -1 if in.available()==0. Then hang goes
> > away, but the Socket gets closed when the InputStream gets closed. If
> > you modify the close() code in
> > org.apache.axis.transport.http.SocketInputStream to deliberately not
> > close the Socket, then you can successfully maintain an HTTP 1.1
> > connection with a non-Axis SOAP server across any number of SOAP calls.
> >
> > The changes in 4) are admittedly a hack, so I next plan to investigate
> > the proposal from Shih-Chang Chen of 4/9/2002 which contains a
> > replacement for HTTPpSender.java and an associated HTTPInputStream.java.
> > This seems like the right way to go. I'm puzzled as to why this
> > submission (and other posts about Keep-Alive) seem to have been ignored.
> > Keep-Alive seems to be worthwhile, especially when SSL is used.
> > -----Original Message-----
> > From: Stocker, Walter [mailto:Walter.Stocker@t-systems.com]
> > Sent: Friday, January 17, 2003 12:51 AM
> > To: axis-user@xml.apache.org
> > Subject: AW: Keep-alive SSL Web Service connections
> >
> >
> > Implement your own SSLSocketFactory with a Socket Pool. I don't
> > know any other way around this.
> >
> > -----Urspr�ngliche Nachricht-----
> > Von: billa@effectnet.com [mailto:billa@effectnet.com]
> > Gesendet: Donnerstag, 16. Januar 2003 19:16
> > An: axis-user@xml.apache.org
> > Betreff: Keep-alive SSL Web Service connections
> >
> >
> >
> > I am designing a web service based application the will require a
> > work
> > flow of web service calls. SSL will be used for transport security. I am
> > concerned about the SSL handshake overhead if each of the web
> > service calls use a new SSL connection. I would like reuse the SSL
> > socket across several calls thus accruing the handshake overhead only
> > once.
> >
> > The Axis JavaDoc indicate that the org.apache.axis.transport.http...
> > invoke methods create a new socket. So it seems that the current
> > implementation does not support using a single HTTP socket across
> > several web service calls.
> >
> > Is there a workaround?
> >
> > Thanks
> > Bill Andrews
> > billa@effectnet.com
>
>
>
>
> ATTACHMENT part 2 application/octet-stream name=HTTPInputStream.java
> ATTACHMENT part 3 application/octet-stream name=HTTPSender.java
=====
Davanum Srinivas - http://xml.apache.org/~dims/
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com