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]>

Reply via email to