Norris, Can you please submit a patch to Bugzilla? (http://nagoya.apache.org/wiki/apachewiki.cgi?SubmitPatches)
Thanks, dims --- Norris Merritt <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 28, 2003 9:54 AM > To: [EMAIL PROTECTED] > 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 > [EMAIL PROTECTED] > > > > 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] > > > > > 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
