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

[Norris Merritt <no...@peregrine.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