tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "B. Balakrishna Rao" <>
Subject RE: Memory leak in using SSL with Tomcat 6.0.18
Date Wed, 04 Aug 2010 14:19:02 GMT
Hi Chris,

Please note that, the 2,996 count is on production environment.
The counts 7 and 10 are on my local environment.

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. After that, I am taking the heap dump.
Eclipse Memory Analyzer tool will do a full GC before it produce the results. Hence,
should be GCed??


-----Original Message-----
From: Christopher Schultz [] 
Sent: Wednesday, August 04, 2010 7:43 PM
To: Tomcat Users List
Subject: Re: Memory leak in using SSL with Tomcat 6.0.18

Hash: SHA1

On 8/4/2010 10:06 AM, B. Balakrishna Rao wrote:
> I have implemented your suggestion. I have deployed my application 
> in Tomcat 6.0.29 version under the same environment as Tomcat
> 6.0.18(test environment).
> After performing the similar operations on both tomcat versions one 
> after another, I have taken the heap dumps from both versions. What I
> observed is: Number of
> objects are 10 in tomcat 6.0.18 and 7 in tomcat 6.0.29.
> I can't able to say that the issue is fixed :(

Neither of these object counts seem unreasonable. Both are much better
than the original report of nearly 3000 object instances.

What is maxThreads set to? I would imagine that there would be a number
SSLSocketImpl objects around for each current connection, plus some that
hadn't yet been GC'd.

- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

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.
View raw message