HTTPUtils#post, which is called for each request, closes the socket before exiting. Therefore, there should not be any open connections for non-gc'ed Call objects, and as things stand, re-using a single Call object does not cause the client to use a single connection.
However, as I have seen with verisign and a mutual fund company with which I have an account, at least some SSL servers do not allow connections to be re-used, anyway. Whether or not my browser connections to this site all use a single SSL session, however, I cannot determine. >From looking at the debug from JSSE and a quick read of some of the original Netscape SSL documentation, there is some SSL traffic for each connection that re-uses a session, but not nearly as much as when a new session is created. (And with JSSE, the single longest activity is generating the original random seed, which is done for the first usage.) Scott Nichol ----- Original Message ----- From: "Niclas Hedhman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, July 06, 2002 2:17 AM Subject: Re: COMProvider patch and ssl question > On Saturday 06 July 2002 06:05, Scott Nichol wrote: > > Furthermore I use https with client and server certificates. > > If I call repeatadly it seems that the client just loose the connection > > now and again. As this happens the call takes "0" seconds as supposed > > to the normal 2-5 seconds. The result is a SOAP-exception that says that > > no HTTP-status has been returned. > > > > I have no clue as to where the problem lies. For each call I create a new > > SOAPHTTPConnection. > > Can anyone tell me if I'm supposed to do something special or maybe explain > > how I can > > find out why the HTTP-status is not there (i.e. why the socket (?) just > > went tired)... > > > > If I use plain HTTP this does not happen. > > Could it be that the Call objects sits in memory (released but non-GCed), > effectively holding the connections to the server, and you run out of Server > connections, which is a couple of dozen on tomcat by default. > > If you are on Linux/Unix, do a netstat to find out. > > Re-using the Call object would eliminate this problem. > > Niclas > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>