From: Betsy Frey [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 10:02 AM
To: [EMAIL PROTECTED]
Subject: RE: Keep-alive SOAP connections are disabled in Axis; Axis hangs if they are enabled
Hi Norris,My Axis server-side code can store things on the javax.servlet.http.HttpSession object, using methods getAttribute and setAttribute. These things remain accessible for the duration of the session, across multiple SOAP requests and responses.Doesn't this mean that the HTTP socket connection is being kept alive?To get the HttpServletRequest:AxisEngine.getCurrentMessageContext().getProperty(HTTPConstants.MC_HTTP_SERVLETREQUEST);To get the HttpSession object from the HttpServletRequest:req.getSession(true); // creates a new HttpSession if one doesn't yet existBetsy-----Original Message-----
From: Norris Merritt [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 10:20 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Keep-alive SOAP connections are disabled in Axis; Axis hangs if they are enabledThanks. I think we are talking about two different things: 1) the concept of SOAP sessions which permits SOAP clients and servers to remember variables and do things like increment counters across multiple different HTTP transactions and 2) re-using a socket connection when the underlying transport is http. I investigated them, and concluded that setMaintainSession() and SimpleSession are for a different purpose than keeping socket connections alive and reusing them for multiple HTTP request/response transactions. They essentially maintain a bag of objects across SOAP calls. HTTPSender gets a new socket factory and a new socket from that socket factory each time invoke() is called, regardless of whether the protocol version is 1.0 or 1.1. So, without some sort of modification to HTTPSender sockets are not going to be reused.-----Original Message-----
From: Betsy Frey [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 7:32 AM
To: [EMAIL PROTECTED]
Subject: RE: Keep-alive SOAP connections are disabled in Axis; Axis hangs if they are enabledThe original message describing how to get persistent sessions working was tucked inside a 2002-12-18 message.
1. modify servlet-config.wsdd (see below; a handler, requestFlow, responseFlow).
2. modify client-config.wsdd (it's in axis.jar; see below; requestFlow, responseFlow).
3. use the same client service for all communications
4. invoke the client service's setMaintainSession(true).The relevant text follows:
List: axis-user
Subject: AW: Deploying the client for session handling using SimpleSession
From: Sebastian.Beyer () wettschereck-partner ! de
Date: 2002-12-18 12:05:18
[Download message RAW]<text omitted>
Am Dienstag, 17. Dezember 2002 16:21 schrieb
[EMAIL PROTECTED]:
> Hi there,
>
> I got it!!! Its unbelievable, but I really got my Sessions working! I
> also deploy my client now. Its rather easy, if you just know exactly
> how to. I'm writing now a small HOWTO, because I got nearly crazy with
> the existing documentation.
>
> So now for everybody who probably like to try, here comes a small
> explanation:
> Note: The wsdd-files are not complete, the shown data is just an
> abridgement of my wsdd-files.
> - I do not use generated classes, like the ones from wsdl2java, but it
> "should" work the same.
>
> server:
> - Write a small service that accesses the session and sets some
> variable inside this session. I took a String that was extended each
> time it is called by an "a" and then returns this String
> - In your server-config file add the SimpleSessionHandler to request
> AND response-flow of the service you want to use with sessions. That
> could look
> like:
>
> <handler name="session"
> type="java:org.apache.axis.handlers.SimpleSessionHandler"/>
> <service name="MyService" provider="java:RPC">
> <requestFlow>
> <handler type="session"/>
> </requestFlow>
> <responseFlow>
> <handler type="session"/>
> </responseFlow>
> <parameter name="allowedMethods" value="*"/>
> <parameter name="scope" value="session"/>
> <parameter name="className" value="MyService"/>
> </service>
>
> client:
> - Write a file named client-config.wsdd and put in a directory in your
> classpath of the client. That could be the root of your
> client-application. Also put in here SimpleSessionHandler in request
> an response-flow; the file could look like:
>
> <globalConfiguration>
> <requestFlow>
> <handler type="session"/>
> </requestFlow>
> <responseFlow>
> <handler type="session"/>
> </responseFlow>
> </globalConfiguration>
> <parameter name="scope" value="session"/>
> <handler name="session"
> type="java:org.apache.axis.handlers.SimpleSessionHandler"/>
>
> - Ensure that on the client you use the same (just once instantiated)
> service-object to create all your calls. That was a big mistake for
> me. I did not take care about this
> - After instantiating your service, set the MaintainSession to true
> before your instantiate your calls from this service.
>
> I think if you follow this, you should see in the SOAP-message (e.g.
> with
> tcpmon) that the session ID is transferred in the sopaenv-header in the
> response and request-message.
> At least that works for me.
>
> hope somebody can use it and wont get grey hair like me :-))
[...]
-----Original Message-----
From: Norris Merritt [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 03, 2003 4:37 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Keep-alive SOAP connections are disabled in Axis; Axis hangs if they are enabled
Hi Betsy, I looked at the several messages posted by Sebastian on 12/17 but didn't find the changes you referred to. I would appreciate it if you would forward that message to me. Re Chen's patches, I'm backing away from them because his version of HTTPSender was created so long ago.
Thanks
-----Original Message-----
From: Betsy Frey [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 03, 2003 2:55 PM
To: [EMAIL PROTECTED]
Subject: RE: Keep-alive SOAP connections are disabled in Axis; Axis hangs if they are enabled
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:[EMAIL PROTECTED]]
Sent: Tuesday, January 28, 2003 12:04 PM
To: '[EMAIL PROTECTED]'
Cc: '[EMAIL PROTECTED]'
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: [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]
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.
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.
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.
