You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@ws.apache.org by Leif Nilsson TACMa <le...@tac.se> on 2002/07/03 15:42:56 UTC

COMProvider patch and ssl question

Hi,

COMPROVIDER
==============
Two memory leaks have now been fixed in RPCProvider.cpp.
If you compare the original version with the new one you'll find two calls
to 
  ::VariantClear(&result);
And one call to 
 ::SysFreeString(bstrS);

I'm not 100% sure that all leaks are handled but it is much better.

Review it and perhaps add it ?

 <<RPCProvider.cpp>> 
SSL-question
==========
I use Java 1.4.0 and Apache soap 2.2
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.

/Leif

Leif Nilsson
Software Engineer

TAC AB
Jägershillgatan 18
SE-213 75 Malmö, Sweden
Direct	+46 40 38 69 56
Fax	+46 40 21 82 87
Mobile	+46 xx xxx xx xx
www.tac-global.com

This email is intended only for the use of the individual or entity to whom
it is addressed. It may contain information that is privileged, confidential
or otherwise protected from disclosure under applicable law. If you have
received this transmission in error, please delete it immediately and notify
me by mailing me.



Re: COMProvider patch and ssl question

Posted by Scott Nichol <sn...@scottnichol.com>.
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.

Re: COMProvider patch and ssl question

Posted by Scott Nichol <sn...@scottnichol.com>.
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" <ni...@ewarna.com>
To: <so...@xml.apache.org>
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:   <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>


Re: COMProvider patch and ssl question

Posted by Niclas Hedhman <ni...@ewarna.com>.
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

Re: COMProvider patch and ssl question

Posted by Niclas Hedhman <ni...@ewarna.com>.
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:   <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>


Re: COMProvider patch and ssl question

Posted by Scott Nichol <sn...@scottnichol.com>.
>>>>
SSL-question
==========
I use Java 1.4.0 and Apache soap 2.2
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.
<<<<

Leif,

Since Apache SOAP uses only a few SSL-specific calls, I fear the behavior my
have something to do with the SSL implementation in the J2SDK.  Have you
attempted to produce a similar problem with a simple example, such as the
URLReader sample from the JSSE reference implementation?  You could add a
loop and/or change the server.

Have you tried any variations, such as JDK 1.3.1 with JSSE 1.0.3?  That's my
config: maybe I'll have a chance to run some tests later.

Scott Nichol



--
To unsubscribe, e-mail:   <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>


Re: COMProvider patch and ssl question

Posted by Scott Nichol <sn...@scottnichol.com>.
Thanks for the COMProvider patch.  I will hopefully look this over sometime
this weekend (it is a long holiday weekend in the U.S.) and commit it to
CVS.

Scott Nichol

----- Original Message -----
From: "Leif Nilsson TACMa" <le...@tac.se>
To: <so...@xml.apache.org>
Sent: Wednesday, July 03, 2002 9:42 AM
Subject: COMProvider patch and ssl question


Hi,

COMPROVIDER
==============
Two memory leaks have now been fixed in RPCProvider.cpp.
If you compare the original version with the new one you'll find two calls
to
  ::VariantClear(&result);
And one call to
 ::SysFreeString(bstrS);

I'm not 100% sure that all leaks are handled but it is much better.

Review it and perhaps add it ?

 <<RPCProvider.cpp>>
SSL-question
==========
I use Java 1.4.0 and Apache soap 2.2
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.

/Leif

Leif Nilsson
Software Engineer

TAC AB
Jägershillgatan 18
SE-213 75 Malmö, Sweden
Direct +46 40 38 69 56
Fax +46 40 21 82 87
Mobile +46 xx xxx xx xx
www.tac-global.com

This email is intended only for the use of the individual or entity to whom
it is addressed. It may contain information that is privileged, confidential
or otherwise protected from disclosure under applicable law. If you have
received this transmission in error, please delete it immediately and notify
me by mailing me.





----------------------------------------------------------------------------
----


> --
> To unsubscribe, e-mail:   <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>


--
To unsubscribe, e-mail:   <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>


Re: COMProvider patch and ssl question

Posted by Scott Nichol <sn...@scottnichol.com>.
Thanks for the COMProvider patch.  I will hopefully look this over sometime
this weekend (it is a long holiday weekend in the U.S.) and commit it to
CVS.

Scott Nichol

----- Original Message -----
From: "Leif Nilsson TACMa" <le...@tac.se>
To: <so...@xml.apache.org>
Sent: Wednesday, July 03, 2002 9:42 AM
Subject: COMProvider patch and ssl question


Hi,

COMPROVIDER
==============
Two memory leaks have now been fixed in RPCProvider.cpp.
If you compare the original version with the new one you'll find two calls
to
  ::VariantClear(&result);
And one call to
 ::SysFreeString(bstrS);

I'm not 100% sure that all leaks are handled but it is much better.

Review it and perhaps add it ?

 <<RPCProvider.cpp>>
SSL-question
==========
I use Java 1.4.0 and Apache soap 2.2
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.

/Leif

Leif Nilsson
Software Engineer

TAC AB
Jägershillgatan 18
SE-213 75 Malmö, Sweden
Direct +46 40 38 69 56
Fax +46 40 21 82 87
Mobile +46 xx xxx xx xx
www.tac-global.com

This email is intended only for the use of the individual or entity to whom
it is addressed. It may contain information that is privileged, confidential
or otherwise protected from disclosure under applicable law. If you have
received this transmission in error, please delete it immediately and notify
me by mailing me.





----------------------------------------------------------------------------
----


> --
> To unsubscribe, e-mail:   <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>


Re: COMProvider patch and ssl question

Posted by Scott Nichol <sn...@scottnichol.com>.
>>>>
SSL-question
==========
I use Java 1.4.0 and Apache soap 2.2
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.
<<<<

Leif,

Since Apache SOAP uses only a few SSL-specific calls, I fear the behavior my
have something to do with the SSL implementation in the J2SDK.  Have you
attempted to produce a similar problem with a simple example, such as the
URLReader sample from the JSSE reference implementation?  You could add a
loop and/or change the server.

Have you tried any variations, such as JDK 1.3.1 with JSSE 1.0.3?  That's my
config: maybe I'll have a chance to run some tests later.

Scott Nichol