tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Botka <>
Subject Re: Tomcat classloader memory leak when an object is stored into session
Date Mon, 10 Feb 2014 20:51:40 GMT
On 07/02/2014, Mark Thomas wrote:

> There is no leak.

Hello Mark,
thank you very mych for help and your great presentation. You were
absolutely right, there was no memory leak :-)
Obviously there was a different issue in my application causing the leak...
I'm sorry for spamming.
Best regards

P.S. Regarding the WebappClassLoader instances I'm suprised that there
is quite often an instance with started=false remaining after garbage
collection is performed. However, this instace is collected later as
the used perm gen memory is reaching the maximum.

2014-02-07 11:46 GMT+01:00 Mark Thomas <>:
> On 07/02/2014 06:38, Michal Botka wrote:
>> Is there a way how to avoid this leak?
> There is no leak.
>> I would like to develop an application which can be safely
>> deployed/undeployed without restarting the server.
> That is very much under your control. I'd suggest reading this:
> as it highlights much of what can go wrong.
>> OK, now I know that my application cannot store it's objects into
>> session, but that is very strong requirement which the most of the
>> applications don't meet.
> There is no such requirement. Storing objects in the session does not
> trigger a memory leak on web application reload.
>> Thanks for help.
>> 2014-02-06 22:58 GMT+01:00 David Kerber <>:
>>> On 2/6/2014 3:13 PM, Michal Botka wrote:
>>>> When an application stores an object into the session and then the
>>>> application is reloaded using Tomcat Web Application Manager, the
>>>> classloader cannot be garbage collected. As a result, the
>>>> "OutOfMemoryError: PermGen space" error occurs after several reloads.
>>> This is true.  What is your question?
> No, this is not true.
>>>> To illustrate the issue, you can find an example below.
>>>> Thanks in advance :-)
> I've taken the provided test code and confirmed - with a profiler - that
> there is no memory leak.
> There is something else that is triggering your memory leak. Follow the
> steps in the presentation above to find out exactly what it is that is
> pinning the web application class loader in memory.
> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message