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:[EMAIL PROTECTED]] Sent: Friday, January 17, 2003 12:51 AM To: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 16. Januar 2003 19:16 An: [EMAIL PROTECTED] 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 [EMAIL PROTECTED]