You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "B. Balakrishna Rao" <ba...@persistent.co.in> on 2010/08/05 13:58:37 UTC

RE: Memory leak in using SSL with Tomcat 6.0.18 - Solved

The problem with memory leak using Tomcat 6.0.18 with SSL+JSSE is solved.
I have implemented native SSL(using Apache APR) instead of JSSE SSL and the problem went away.
Thanks for your help on this.

Please note that memory leak using with SSL+JSSE is still exist on tomcat 6.0.29 version.

Thanks,
Bala.

-----Original Message-----
From: B. Balakrishna Rao 
Sent: Thursday, August 05, 2010 10:17 AM
To: Tomcat Users List
Subject: RE: Memory leak in using SSL with Tomcat 6.0.18

Hi Chris,

Attached is the image for incoming references for com.sun.net.ssl.internal.ssl.SSLSocketImpl objects.
Please let me know if you want any further details.

Thanks,


-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net]
Sent: Wednesday, August 04, 2010 10:14 PM
To: Tomcat Users List
Subject: Re: Memory leak in using SSL with Tomcat 6.0.18

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

B.,

On 8/4/2010 10:19 AM, B. Balakrishna Rao wrote:
> Please note that, the 2,996 count is on production environment.
> The counts 7 and 10 are on my local environment.

Ok.

> Below is the procedure I am following on my local environment to test this:
> 
> Log in -> do some operations -> log out.
> I am calling session.invalidate() method upon log out.

Whether you log out of not shouldn't have anything to do with these objects staying around.

> After that, I am taking the heap dump. Eclipse Memory Analyzer tool 
> will do a full GC before it produce the results. Hence, 
> com.sun.net.ssl.internal.ssl.SSLSocketImpl should be GCed??

Most likely.

Since you're using a profiler, can you show us what the stack trace is of the code that created the SSLSocketImpl objects?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxZmNEACgkQ9CaO5/Lv0PA3DwCdEpwgPIclWBmmlfM+wD5VX0w4
YPIAn2P5+aVG9u8UswVYPEd5ctXh2jO1
=kV3t
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.

RE: Memory leak in using SSL with Tomcat 6.0.18 - Solved

Posted by Sarath Babu Polavarapu <sa...@persistent.co.in>.
Good Work Bala.

-----Original Message-----
From: B. Balakrishna Rao [mailto:balakrishna_rao@persistent.co.in] 
Sent: Thursday, August 05, 2010 5:29 PM
To: Tomcat Users List
Subject: RE: Memory leak in using SSL with Tomcat 6.0.18 - Solved

The problem with memory leak using Tomcat 6.0.18 with SSL+JSSE is solved.
I have implemented native SSL(using Apache APR) instead of JSSE SSL and the problem went away.
Thanks for your help on this.

Please note that memory leak using with SSL+JSSE is still exist on tomcat 6.0.29 version.

Thanks,
Bala.

-----Original Message-----
From: B. Balakrishna Rao 
Sent: Thursday, August 05, 2010 10:17 AM
To: Tomcat Users List
Subject: RE: Memory leak in using SSL with Tomcat 6.0.18

Hi Chris,

Attached is the image for incoming references for com.sun.net.ssl.internal.ssl.SSLSocketImpl objects.
Please let me know if you want any further details.

Thanks,


-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net]
Sent: Wednesday, August 04, 2010 10:14 PM
To: Tomcat Users List
Subject: Re: Memory leak in using SSL with Tomcat 6.0.18

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

B.,

On 8/4/2010 10:19 AM, B. Balakrishna Rao wrote:
> Please note that, the 2,996 count is on production environment.
> The counts 7 and 10 are on my local environment.

Ok.

> Below is the procedure I am following on my local environment to test this:
> 
> Log in -> do some operations -> log out.
> I am calling session.invalidate() method upon log out.

Whether you log out of not shouldn't have anything to do with these objects staying around.

> After that, I am taking the heap dump. Eclipse Memory Analyzer tool 
> will do a full GC before it produce the results. Hence, 
> com.sun.net.ssl.internal.ssl.SSLSocketImpl should be GCed??

Most likely.

Since you're using a profiler, can you show us what the stack trace is of the code that created the SSLSocketImpl objects?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxZmNEACgkQ9CaO5/Lv0PA3DwCdEpwgPIclWBmmlfM+wD5VX0w4
YPIAn2P5+aVG9u8UswVYPEd5ctXh2jO1
=kV3t
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.

DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.