RE: Keep-alive SOAP connections are disabled in Axis; Axis hangs if they are enabled

[Betsy Frey <Be...@merant.com>]

I think the problem of non-persistent connections only shows up if you're
using HTTP/1.1.
  
I'm seeing persistent connections, with no hang (because I'm using an Axis
server), without Chen's patches, using HTTP/1.0.  I made the simple changes
described in Sebastian Beyer's 17 Dec 2002 mail, and they worked fine.

The problem described in #1 below should say "HTTPSender.java deliberately
generates a Connection:close header IF HTTP 1.0 is NOT set".

Betsy

-----Original Message-----
From: Norris Merritt [mailto:norris.merritt@peregrine.com] 
Sent: Tuesday, January 28, 2003 12:04 PM
To: 'billa@effectnet.com'
Cc: 'axis-user@xml.apache.org'
Subject: 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




Notice: This email transmission and/or the attachments accompanying it may
contain confidential information belonging to Merant. The information is
only for the use of the intended recipient. If you have received this
transmission in error, please notify the sender immediately by reply email,
and then destroy all copies of the transmission.