You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jon Miller <je...@uchicago.edu> on 2006/11/28 01:37:51 UTC

Memory leaks on webapp redeploy

Hi all,

Is anyone running into issues with memory leaks occuring whenever a webapp 
is redeployed? I've been having a lot of problems with this. I think what's 
exacerbating the problem is that I'm using Hibernate and JAX-WS which I have 
bundled with my application which use a lot of memory.

I think I read in a FAQ that even using a singleton in your app will cause 
memory leaks? Does anyone know if this is true?

Jon


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


RE: Memory leaks on webapp redeploy

Posted by Re...@sanofipasteur.com.
> It's been a while since I profiled any of my apps, but that 
> used to be the case... after a few days in development of 
> auto-re-loading the webapps, we'd get an OOM. We could watch 
> the heap fill up with useless Class objects (for instance, 
> my.package.Class showed up 10 times after 9 restarts, and we 
> don't do anything crazy like keeping Class references around, 
> singletons, thread locals variables, static class data, etc.).

Same problem here. Reloading such a tiny webapp generates memory leaks
in the PermGenSpace (which is a non-heap space).
Some libraries (apparently cglib) kept some Classloaders references and
don't free them. This leads to an OOM : Out of PermgenSpace after some
reloads (or redeploy)
We have try to setup a "cleaner" ServletContextListener to force some
cleaning job (Introspector caches) on contextDestroyed event, but it
doesn't give any more results.

Profiling instrumentations gave us some informations about what is
loaded. But it's quite difficult to find the "guilty" source.

I'm very interested in the following of this issue.

RC

-------------------------------------------------------------------------------------------
"Cette communication (y compris les pieces jointes) est reservee a l'usage exclusif du destinataire (des destinataires) et peut contenir des informations privilegiees, confidentielles, exemptees de divulgation selon la loi ou protegees par les droits d'auteur. Si vous n'etes pas un destinataire, toute utilisation, divulgation, distribution, reproduction, examen ou copie (totale ou partielle) est non-autorisee et peut etre illegale. Tout message electronique est susceptible d'alteration et son integrite ne peut etre assuree. Sanofi Pasteur decline toute responsabilite au titre de ce message s'il a ete modifie ou falsifie. Si vous n'etes pas destinataire de ce message, merci de le detruire immediatement et d'avertir l'expediteur de l'erreur de distribution et de la destruction du message. Merci.
This transmission (including any attachments) is intended solely for the use of the addressee(s) and may contain confidential information including trade secrets which are privileged, confidential, exempt from disclosure under applicable law and/or subject to copyright. If you are not an intended recipient, any use, disclosure, distribution, reproduction, review or copying (either whole or partial) is unauthorized and may be unlawful. E-mails are susceptible to alteration and their integrity cannot be guaranteed.Sanofi Pasteur shall not be liable for this e-mail if modified or falsified. If you are not the intended recipient of this e-mail, please delete it immediately from your system and notify the sender of the wrong delivery and the mail deletion. Thank you."
**********************************************************************


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


RE: Memory leaks on webapp redeploy

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Christopher Schultz [mailto:chris@christopherschultz.net] 
> Subject: Re: Memory leaks on webapp redeploy
> 
> Maybe this issue has been fixed in recent VMs (IIRC, older 
> VMs -- maybe 1.3-era -- would never discard java.lang.Class
> objects.

Not true either.  I've been porting Sun's JVMs to various platforms
since 1.2, and GC of classes has always been available (not sure about
1.1).

> Java 1.5 has the "-Xnoclassgc" option

That's also been around since at least 1.3.

> For instance, if you had a singleton with a static instance of the
> class, but no references to the Class object, no instances other than
> the singleton (a reasonable assumption for a singleton), and 
> no outside references to the singleton object, then the VM is within 
> it's rights to discard both the instance and the Class since they are 
> "unused". I seem to recall this being a problem for folks who thought
> that singletons were a good idea, and so the Java folks decided to
keep
> Class objects around forever.

The first part is true, the latter conclusion isn't, at least not in
Sun-based JVMs.  You do have to be careful if only reflection is used to
access a class, since it can disappear as you described.

> Or am I just crazy and making the whole thing up? ;)

Always a possibility, especially in this business :-)

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

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


RE: Memory leaks on webapp redeploy

Posted by Re...@sanofipasteur.com.

http://wiki.apache.org/tomcat/OutOfMemory : Another link which deals
about OOM and singleton.

Have you ever tried to do some inspections with decent profiler
(OptimiseIt, Jprofiler, Yourkit, ...) ?

RC
-------------------------------------------------------------------------------------------
"Cette communication (y compris les pieces jointes) est reservee a l'usage exclusif du destinataire (des destinataires) et peut contenir des informations privilegiees, confidentielles, exemptees de divulgation selon la loi ou protegees par les droits d'auteur. Si vous n'etes pas un destinataire, toute utilisation, divulgation, distribution, reproduction, examen ou copie (totale ou partielle) est non-autorisee et peut etre illegale. Tout message electronique est susceptible d'alteration et son integrite ne peut etre assuree. Sanofi Pasteur decline toute responsabilite au titre de ce message s'il a ete modifie ou falsifie. Si vous n'etes pas destinataire de ce message, merci de le detruire immediatement et d'avertir l'expediteur de l'erreur de distribution et de la destruction du message. Merci.
This transmission (including any attachments) is intended solely for the use of the addressee(s) and may contain confidential information including trade secrets which are privileged, confidential, exempt from disclosure under applicable law and/or subject to copyright. If you are not an intended recipient, any use, disclosure, distribution, reproduction, review or copying (either whole or partial) is unauthorized and may be unlawful. E-mails are susceptible to alteration and their integrity cannot be guaranteed.Sanofi Pasteur shall not be liable for this e-mail if modified or falsified. If you are not the intended recipient of this e-mail, please delete it immediately from your system and notify the sender of the wrong delivery and the mail deletion. Thank you."
**********************************************************************


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


Re: Memory leaks on webapp redeploy

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chuck,

Caldarale, Charles R wrote:
>> Subject: Re: Memory leaks on webapp redeploy
>>
>> The only thing I can think of is perhaps Java is keeping introspection
>> information around and never releasing it.
> 
> Quite possible.  There's a good discussion of the issue here:
> http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?
> pageId=2669

Yup; that's where I read about the Introspector.flushCaches trick. I use
Velocity, not JSP, and I just checked the source code for their
introspection code, and it does not appear to use the built-in Java
Introspector, so that's unlikely to be the problem. Velocity is the only
place that we use any introspection at all, so I'll be interested to see
the results of profiling.... especially which objects are holding on to
references to old Class objects.

Maybe this issue has been fixed in recent VMs (IIRC, older VMs -- maybe
1.3-era -- would never discard java.lang.Class objects. Java 1.5 has the
"-Xnoclassgc" option, which might exist to replicate this "feature" for
apps which relied on Class objects living forever.

For instance, if you had a singleton with a static instance of the
class, but no references to the Class object, no instances other than
the singleton (a reasonable assumption for a singleton), and no outside
references to the singleton object, then the VM is within it's rights to
discard both the instance and the Class since they are "unused". I seem
to recall this being a problem for folks who thought that singletons
were a good idea, and so the Java folks decided to keep Class objects
around forever.

Perhaps that changed. Anyone know about the history of this phenomenon?
Or am I just crazy and making the whole thing up? ;)

- -chris

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

iD8DBQFFbGTL9CaO5/Lv0PARAt2yAKCDRa6Mx0ojhSdyHfYmZkKLoVL6hACgikgU
USkA4X4E2DIy9vk/Qwxs5d0=
=/sNx
-----END PGP SIGNATURE-----

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


RE: Memory leaks on webapp redeploy

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Christopher Schultz [mailto:chris@christopherschultz.net] 
> Subject: Re: Memory leaks on webapp redeploy
> 
> This wasn't the case some time ago. A cleanly written webapp would
> double the number of Class objects kept around after a re-deploy
> (actually, after an automatic re-deploy, but that shouldn't 
> have mattered).

I was referring to the generic nature of your statement, not the
specifics of running within Tomcat.

> The only thing I can think of is perhaps Java is keeping introspection
> information around and never releasing it.

Quite possible.  There's a good discussion of the issue here:
http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?
pageId=2669

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

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


Re: Memory leaks on webapp redeploy

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chuck,

Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:chris@christopherschultz.net] 
>> Subject: Re: Memory leaks on webapp redeploy
>>
>> Last time I checked, Class objects basically never get GC'd,
>> so any static data stays around forever. You have to shut
>> down the VM in order to free that memory.
> 
> Not true - classes do get cleaned up, if there are no references to
> them.

This wasn't the case some time ago. A cleanly written webapp would
double the number of Class objects kept around after a re-deploy
(actually, after an automatic re-deploy, but that shouldn't have mattered).

It's been a while since I profiled any of my apps, but that used to be
the case... after a few days in development of auto-re-loading the
webapps, we'd get an OOM. We could watch the heap fill up with useless
Class objects (for instance, my.package.Class showed up 10 times after 9
restarts, and we don't do anything crazy like keeping Class references
around, singletons, thread locals variables, static class data, etc.).

The only thing I can think of is perhaps Java is keeping introspection
information around and never releasing it. If that's the case, it looks
like a call to java.beans.Introspector.flushCaches() would have fixed my
problem.

I'll look into this, if I can figure out how to get my copy of
OptimizeIt working again. Wow. I really need to get a profiler that was
written in the new millennium, eh?

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

iD8DBQFFbFpE9CaO5/Lv0PARArqaAKC3PG1uOU8MbghsntHZxNvaHS1cvgCggJAr
2x6LO1cKa73h9FwdBBBL9mI=
=d4hC
-----END PGP SIGNATURE-----

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


RE: Memory leaks on webapp redeploy

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Christopher Schultz [mailto:chris@christopherschultz.net] 
> Subject: Re: Memory leaks on webapp redeploy
> 
> Last time I checked, Class objects basically never get GC'd,
> so any static data stays around forever. You have to shut
> down the VM in order to free that memory.

Not true - classes do get cleaned up, if there are no references to
them.  If you turn on enough GC tracing options, you can see this
happening, especially with anonymous classes, which are created and
destroyed with great frequency.  The problem is retained references to
either the associated classloader or instances of java.lang.Class; as
long as these exist, the class objects won't go away.

(The reports that JRockit doesn't run into the OOME is either a bug in
JRockit - releasing classes while there are still references to them -
or an aspect of JRockit not segregating java.lang.Class instances in a
relatively small space separate from the rest of the heap.)

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

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


Re: Memory leaks on webapp redeploy

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jon,

Jon Miller wrote:
> Is anyone running into issues with memory leaks occuring whenever a
> webapp is redeployed?

This is probably not Tomcat's fault.... it's Java's fault.

When Tomcat reloads a webapp, it discards the ClassLoader (or
ClassLoaders) that were being used by the old instance. These
ClassLoader objects contain information about the (duh) Classes that
were loaded during your old instance's activity.

Last time I checked, Class objects basically never get GC'd, so any
static data stays around forever. You have to shut down the VM in order
to free that memory.

This is one reason that I bounce my VM whenever I release new app
versions to production.

- -chris

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

iD8DBQFFbFVj9CaO5/Lv0PARAiRrAJsFfoFlkoMPZLu9jtaaT3xvWCX8FQCeM7/k
XnEmBvVmXc8wrUWbjmnmvpA=
=xjI3
-----END PGP SIGNATURE-----

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


Re: Memory leaks on webapp redeploy

Posted by Nicholas Sushkin <ns...@openfinance.com>.
On Monday 27 November 2006 19:37, Jon Miller wrote: 

> Is anyone running into issues with memory leaks occuring whenever a
> webapp is redeployed? 

Yes ... :)

> I've been having a lot of problems with this. I 
> think what's exacerbating the problem is that I'm using Hibernate and
> JAX-WS which I have bundled with my application which use a lot of
> memory.
>
> I think I read in a FAQ that even using a singleton in your app will
> cause memory leaks? Does anyone know if this is true?

It seems to be true if you implement your singletons using static instances. 
The way I understand it, each time you redeploy, Tomcat will reload your 
classes and as the result, create another set of instances of your 
singletons. See the description of the problem and some workarounds in

http://wiki.apache.org/tomcat/OutOfMemory

-- 
Nicholas Sushkin, Senior Software Engineer
Open Finance, Chelsea Piers Pier 62 Suite 316, New York NY 10011
Tel +1 646 723 2790 Fax +1 646 723 2789 nsushkin@openfinance.com

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


Re: Memory leaks on webapp redeploy

Posted by Jon Miller <je...@uchicago.edu>.
Currently I'm using 5.5.17, but, it's happened with every other version that 
I've used for the past several years as well.

Jon

----- Original Message ----- 
From: "Mark Thomas" <ma...@apache.org>
To: "Tomcat Users List" <us...@tomcat.apache.org>
Sent: Monday, November 27, 2006 7:37 PM
Subject: Re: Memory leaks on webapp redeploy


> Jon Miller wrote:
>> Hi all,
>>
>> Is anyone running into issues with memory leaks occuring whenever a
>> webapp is redeployed?
>
> Tomcat version? There have been issues with older releases.
>
>> I think I read in a FAQ that even using a singleton in your app will
>> cause memory leaks? Does anyone know if this is true?
>
> It depends on how careful you are using it. There are lots of ways to
> write code that leaks memory.
>
> Rather than try guessing where the leak is, get yourself a profiler
> and find it.
>
> Mark
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 


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


Re: Memory leaks on webapp redeploy

Posted by Jon Miller <je...@uchicago.edu>.
----- Original Message ----- 
From: "Christopher Schultz" <ch...@christopherschultz.net>
To: "Tomcat Users List" <us...@tomcat.apache.org>
Sent: Tuesday, November 28, 2006 11:46 AM
Subject: Re: Memory leaks on webapp redeploy


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jon,
>
> Jon Miller wrote:
>> I'm getting ready to try NetBeans profiler right now. I tried it awhile
>> back before it was released, but, there was something wrong with the
>> Solaris library, so, I couldn't get it to work. I'm hoping I'll have
>> better luck now that it's been released officially.
>
> I downloaded the Linux version of JProbe's profiler, and I can't figure
> out how to start it. The only "binary" that makes any sense is
> jpprofiler, and that gives me a "DISPLAY is inaccessible" error, even
> though I can run xterm and xclock and stuff no problem. :(
>
> Let me know how it goes with the NetBeans profiler. Also, let me know if
> it was easy to get going. I'd love to use something that I can attach to
> a running process -- sorta like Sun's jconsole.

I'm not sure I would recommend NetBeans profiler. I ran into a few different 
issues. It's pretty easy to install and the interface seems pretty 
intuitive. I was able to kind of get it to work running NetBeans on a 
Windows XP system (1.5Ghz Pentium IV) and remotely debugging Tomcat on a 
Solaris system. However, I received some errors in the log about it not 
being able to load some class files. It looked like it might have had to do 
with classes that were generated dynamically (probably Hibernate proxies). 
For some reason, I couldn't find my applications classes. I could see 
Hibernate and JAX-WS related classes, but, mine weren't there. Then, it 
locked up. It did that twice. Then, I switched to trying to profile it on a 
local installation of Tomcat. I found that it kind of worked albeit 
extremely slowly if I selected the "Analyze Memory Usage" option and only 
"Record object creation only." If I tried "Record both object creation and 
garbage collection" or "Record Stack Trace for Allocations" options, it ran 
so slow that my mouse cursor wouldn't even move.

I think what I may end up having to do is simply restart Tomcat everytime I 
do a redeploy. Strange how I haven't run into these issues with the ASP.NET 
apps that I've developed. Also strange how a problem like this could go on 
for YEARS without being fixed.

Jon

> - -chris
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFbHXp9CaO5/Lv0PARAot6AJ4rVIkv4lKHpDXm18gzCQky4FBOgACfa+Hl
> alSevcwHO7SLhpblRcOKm8I=
> =DVpu
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 


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


Re: Memory leaks on webapp redeploy

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jon,

Jon Miller wrote:
> I'm getting ready to try NetBeans profiler right now. I tried it awhile
> back before it was released, but, there was something wrong with the
> Solaris library, so, I couldn't get it to work. I'm hoping I'll have
> better luck now that it's been released officially.

I downloaded the Linux version of JProbe's profiler, and I can't figure
out how to start it. The only "binary" that makes any sense is
jpprofiler, and that gives me a "DISPLAY is inaccessible" error, even
though I can run xterm and xclock and stuff no problem. :(

Let me know how it goes with the NetBeans profiler. Also, let me know if
it was easy to get going. I'd love to use something that I can attach to
a running process -- sorta like Sun's jconsole.

- -chris

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

iD8DBQFFbHXp9CaO5/Lv0PARAot6AJ4rVIkv4lKHpDXm18gzCQky4FBOgACfa+Hl
alSevcwHO7SLhpblRcOKm8I=
=DVpu
-----END PGP SIGNATURE-----

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


Re: Memory leaks on webapp redeploy

Posted by Jon Miller <je...@uchicago.edu>.
I'm getting ready to try NetBeans profiler right now. I tried it awhile back 
before it was released, but, there was something wrong with the Solaris 
library, so, I couldn't get it to work. I'm hoping I'll have better luck now 
that it's been released officially.

Jon

----- Original Message ----- 
From: "anjan bacchu" <an...@gmail.com>
To: "Tomcat Users List" <us...@tomcat.apache.org>
Sent: Monday, November 27, 2006 8:08 PM
Subject: Re: Memory leaks on webapp redeploy


> Hi Mark,
>
>  Does anyone on the tomcat dev list use Netbeans profiler at all ? OR do
> you guys
> exclusively use YourKit ?
>
> Thank you,
>
> BR,
> ~A
>
> On 11/27/06, Mark Thomas <ma...@apache.org> wrote:
>>
>> Jon Miller wrote:
>> > Hi all,
>> >
>> > Is anyone running into issues with memory leaks occuring whenever a
>> > webapp is redeployed?
>>
>> Tomcat version? There have been issues with older releases.
>>
>> > I think I read in a FAQ that even using a singleton in your app will
>> > cause memory leaks? Does anyone know if this is true?
>>
>> It depends on how careful you are using it. There are lots of ways to
>> write code that leaks memory.
>>
>> Rather than try guessing where the leak is, get yourself a profiler
>> and find it.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
> -- 
> BR,
> Anjan Bacchu
> Summit Information Systems
> 


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


Re: Memory leaks on webapp redeploy

Posted by anjan bacchu <an...@gmail.com>.
Hi Mark,

  Does anyone on the tomcat dev list use Netbeans profiler at all ? OR do
you guys
exclusively use YourKit ?

Thank you,

BR,
~A

On 11/27/06, Mark Thomas <ma...@apache.org> wrote:
>
> Jon Miller wrote:
> > Hi all,
> >
> > Is anyone running into issues with memory leaks occuring whenever a
> > webapp is redeployed?
>
> Tomcat version? There have been issues with older releases.
>
> > I think I read in a FAQ that even using a singleton in your app will
> > cause memory leaks? Does anyone know if this is true?
>
> It depends on how careful you are using it. There are lots of ways to
> write code that leaks memory.
>
> Rather than try guessing where the leak is, get yourself a profiler
> and find it.
>
> Mark
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


-- 
BR,
Anjan Bacchu
Summit Information Systems

Re: Memory leaks on webapp redeploy

Posted by Martin Gainty <mg...@hotmail.com>.
Jon-

A couple of things that may be of immediate use to you (even for older releases)
Confine your variables to have as restricted scope as possible in other words
If you have a number of JSP tags that are application scope and get by with request then convert those tags to use request scope
If you're using 1.. n new allocations inside of a method use gc() at the end of that method to force the garbage collector to recover the allocations
for profiler try http://pmd.sourceforge.net/ which will easily integrate with Ant or Maven builds..

Feel free to follow up with any specific questions

I hope this helps you,
Martin
This e-mail communication and any attachments may contain confidential and privileged information for the use of the 
designated recipients named above. If you are not the intended recipient, you are hereby notified that you have received
this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its 
contents
----- Original Message ----- 
From: "Mark Thomas" <ma...@apache.org>
To: "Tomcat Users List" <us...@tomcat.apache.org>
Sent: Monday, November 27, 2006 8:37 PM
Subject: Re: Memory leaks on webapp redeploy


> Jon Miller wrote:
>> Hi all,
>> 
>> Is anyone running into issues with memory leaks occuring whenever a
>> webapp is redeployed?
> 
> Tomcat version? There have been issues with older releases.
> 
>> I think I read in a FAQ that even using a singleton in your app will
>> cause memory leaks? Does anyone know if this is true?
> 
> It depends on how careful you are using it. There are lots of ways to
> write code that leaks memory.
> 
> Rather than try guessing where the leak is, get yourself a profiler
> and find it.
> 
> Mark
> 
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
>

Re: Memory leaks on webapp redeploy

Posted by Mark Thomas <ma...@apache.org>.
Jon Miller wrote:
> Hi all,
> 
> Is anyone running into issues with memory leaks occuring whenever a
> webapp is redeployed?

Tomcat version? There have been issues with older releases.

> I think I read in a FAQ that even using a singleton in your app will
> cause memory leaks? Does anyone know if this is true?

It depends on how careful you are using it. There are lots of ways to
write code that leaks memory.

Rather than try guessing where the leak is, get yourself a profiler
and find it.

Mark

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


Re: Memory leaks on webapp redeploy

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Remy,

Remy.Coqueugniot@sanofipasteur.com wrote:
>> That means, that hibernate apps will always generate OOM...
> 
> Not always. But some hibernate/cglib/tomcat uses seems to generate
> classloader memory leak:
> http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?
> pageId=2669
> 
> You can easily reproduce this behaviour.
> Write a quite empty webapp with hibernate (so cglib too) which contains
> just a JSP/servlet which do a dummy DBMS request (select sysdate from
> dual) and print the result.
>  -Deploy it 
>  -access to your JSP/servlet
>  -reload webapp
> Write a Jmeter scenario that execute those 2 last steps.
> Repeat it many times (<10 times for a default heap sized JVM)
> You will see your Permgenspace always growing and crash at the high
> level (64MB default)

Can you confirm the types of objects that are filling up the
Permgenspace, or just that it is filling up. I'd love to know if you're
overflowing with Class, String, and char[] objects (which are the
offenders when ClassLoaders cannot unload their Class objects).

- -chris

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

iD8DBQFFbFaE9CaO5/Lv0PARAqAQAJ9FRw9jWZiNgv8WMVoHn3rbSEgqNwCdEezp
I27aI0oZuDkURlyiLPFcpLE=
=XJwy
-----END PGP SIGNATURE-----

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


RE: Memory leaks on webapp redeploy

Posted by Re...@sanofipasteur.com.
> > The problems seems to be located with Cglib classloaders 
> referencing 
> > policy. There is a lot of topic on the Net, which may be 
> interessing 
> > to read, but noone seems to have found a valuable solution. 
> > (Increasing the PermGenspace is NOT a reasonable solution)
> >   
> That means, that hibernate apps will always generate OOM...

Not always. But some hibernate/cglib/tomcat uses seems to generate
classloader memory leak:
http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?
pageId=2669

You can easily reproduce this behaviour.
Write a quite empty webapp with hibernate (so cglib too) which contains
just a JSP/servlet which do a dummy DBMS request (select sysdate from
dual) and print the result.
 -Deploy it 
 -access to your JSP/servlet
 -reload webapp
Write a Jmeter scenario that execute those 2 last steps.
Repeat it many times (<10 times for a default heap sized JVM)
You will see your Permgenspace always growing and crash at the high
level (64MB default)


> > The only way we found to fix it is to change the JVM. 
> Indeed if we use the BEA Jrockit 1.4 JVM, the application can 
> be deployed as many times you want...
> >   
> Great news! Do you know whether their JVM (1.5) is free to 
> download and use?
Yes it's free to download. For a commercial use you should check the
license.
But keep in mind, that may be a dangerous alternative. You don't know
yet what could append with Jrockit.
And the past releases don't tend to be stable as a sun one (to my
experiences)

Out solution is to install one instance of Tomcat per application :
reducing memory heap use, ...
And for each redeploy/reload we restart the tomcat service.
A Heavy but working solution ....

RC

-------------------------------------------------------------------------------------------
"Cette communication (y compris les pieces jointes) est reservee a l'usage exclusif du destinataire (des destinataires) et peut contenir des informations privilegiees, confidentielles, exemptees de divulgation selon la loi ou protegees par les droits d'auteur. Si vous n'etes pas un destinataire, toute utilisation, divulgation, distribution, reproduction, examen ou copie (totale ou partielle) est non-autorisee et peut etre illegale. Tout message electronique est susceptible d'alteration et son integrite ne peut etre assuree. Sanofi Pasteur decline toute responsabilite au titre de ce message s'il a ete modifie ou falsifie. Si vous n'etes pas destinataire de ce message, merci de le detruire immediatement et d'avertir l'expediteur de l'erreur de distribution et de la destruction du message. Merci.
This transmission (including any attachments) is intended solely for the use of the addressee(s) and may contain confidential information including trade secrets which are privileged, confidential, exempt from disclosure under applicable law and/or subject to copyright. If you are not an intended recipient, any use, disclosure, distribution, reproduction, review or copying (either whole or partial) is unauthorized and may be unlawful. E-mails are susceptible to alteration and their integrity cannot be guaranteed.Sanofi Pasteur shall not be liable for this e-mail if modified or falsified. If you are not the intended recipient of this e-mail, please delete it immediately from your system and notify the sender of the wrong delivery and the mail deletion. Thank you."
**********************************************************************


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


Re: Memory leaks on webapp redeploy

Posted by Mikolaj Rydzewski <mi...@ceti.pl>.
Remy.Coqueugniot@sanofipasteur.com wrote:
> The problems seems to be located with Cglib classloaders referencing policy. There is a lot of topic on the Net, which may be interessing to read, but noone seems to have found a valuable solution. (Increasing the PermGenspace is NOT a reasonable solution)
>   
That means, that hibernate apps will always generate OOM...
> The only way we found to fix it is to change the JVM. Indeed if we use the BEA Jrockit 1.4 JVM, the application can be deployed as many times you want...
>   
Great news! Do you know whether their JVM (1.5) is free to download and use?

-- 
Mikolaj Rydzewski <mi...@ceti.pl>


Re: Memory leaks on webapp redeploy

Posted by Jon Miller <je...@uchicago.edu>.
Thanks for the info Remy. I've been using Sun's JVM, but, I think I'm going 
to try IBM's to see if that makes a difference.

Jon

----- Original Message ----- 
From: <Re...@sanofipasteur.com>
To: <us...@tomcat.apache.org>
Sent: Tuesday, November 28, 2006 3:30 AM
Subject: RE: Memory leaks on webapp redeploy


>> Is anyone running into issues with memory leaks occuring
>> whenever a webapp is redeployed? I've been having a lot of
>> problems with this. I think what's exacerbating the problem
>> is that I'm using Hibernate and JAX-WS which I have bundled
>> with my application which use a lot of memory.
>
> Yes, we experience same problems with Tomcat 5.5.17
>
> We did a lot of tests and profiling instrumentations (Jprofiler powered) 
> on many environments : Win32/Linux,  JDK1.4.2_12, JDL 1.5, Tomcat 
> 5.5.17/5.5.20
> Same problem: many redeployments (or reload) of a webapp throw an 
> OutOfMemory for the PermGenspace. If you monitor your Jvm with Jvmstat 
> tools you would see this non-heap memory never been released...
>
> The problems seems to be located with Cglib classloaders referencing 
> policy. There is a lot of topic on the Net, which may be interessing to 
> read, but noone seems to have found a valuable solution. (Increasing the 
> PermGenspace is NOT a reasonable solution)
>
> The only way we found to fix it is to change the JVM. Indeed if we use the 
> BEA Jrockit 1.4 JVM, the application can be deployed as many times you 
> want...
>
> Please give some news, if you find something useful
>
> RC
>
>
>> -----Message d'origine-----
>> De : Jon Miller [mailto:jemiller@uchicago.edu]
>> Envoyé : mardi 28 novembre 2006 01:38
>> À : Tomcat User List
>> Objet : Memory leaks on webapp redeploy
>>
>> Hi all,
>>
>>
>> I think I read in a FAQ that even using a singleton in your
>> app will cause memory leaks? Does anyone know if this is true?
>>
>> Jon
>>
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org To
>> unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
> -------------------------------------------------------------------------------------------
> "Cette communication (y compris les pieces jointes) est reservee a l'usage 
> exclusif du destinataire (des destinataires) et peut contenir des 
> informations privilegiees, confidentielles, exemptees de divulgation selon 
> la loi ou protegees par les droits d'auteur. Si vous n'etes pas un 
> destinataire, toute utilisation, divulgation, distribution, reproduction, 
> examen ou copie (totale ou partielle) est non-autorisee et peut etre 
> illegale. Tout message electronique est susceptible d'alteration et son 
> integrite ne peut etre assuree. Sanofi Pasteur decline toute 
> responsabilite au titre de ce message s'il a ete modifie ou falsifie. Si 
> vous n'etes pas destinataire de ce message, merci de le detruire 
> immediatement et d'avertir l'expediteur de l'erreur de distribution et de 
> la destruction du message. Merci.
> This transmission (including any attachments) is intended solely for the 
> use of the addressee(s) and may contain confidential information including 
> trade secrets which are privileged, confidential, exempt from disclosure 
> under applicable law and/or subject to copyright. If you are not an 
> intended recipient, any use, disclosure, distribution, reproduction, 
> review or copying (either whole or partial) is unauthorized and may be 
> unlawful. E-mails are susceptible to alteration and their integrity cannot 
> be guaranteed.Sanofi Pasteur shall not be liable for this e-mail if 
> modified or falsified. If you are not the intended recipient of this 
> e-mail, please delete it immediately from your system and notify the 
> sender of the wrong delivery and the mail deletion. Thank you."
> **********************************************************************
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
> 


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


RE: Memory leaks on webapp redeploy

Posted by Re...@sanofipasteur.com.
> Is anyone running into issues with memory leaks occuring 
> whenever a webapp is redeployed? I've been having a lot of 
> problems with this. I think what's exacerbating the problem 
> is that I'm using Hibernate and JAX-WS which I have bundled 
> with my application which use a lot of memory.

Yes, we experience same problems with Tomcat 5.5.17 

We did a lot of tests and profiling instrumentations (Jprofiler powered) on many environments : Win32/Linux,  JDK1.4.2_12, JDL 1.5, Tomcat 5.5.17/5.5.20
Same problem: many redeployments (or reload) of a webapp throw an OutOfMemory for the PermGenspace. If you monitor your Jvm with Jvmstat tools you would see this non-heap memory never been released...

The problems seems to be located with Cglib classloaders referencing policy. There is a lot of topic on the Net, which may be interessing to read, but noone seems to have found a valuable solution. (Increasing the PermGenspace is NOT a reasonable solution)

The only way we found to fix it is to change the JVM. Indeed if we use the BEA Jrockit 1.4 JVM, the application can be deployed as many times you want...

Please give some news, if you find something useful

RC


> -----Message d'origine-----
> De : Jon Miller [mailto:jemiller@uchicago.edu] 
> Envoyé : mardi 28 novembre 2006 01:38
> À : Tomcat User List
> Objet : Memory leaks on webapp redeploy
> 
> Hi all,
> 
> 
> I think I read in a FAQ that even using a singleton in your 
> app will cause memory leaks? Does anyone know if this is true?
> 
> Jon
> 
> 
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org To 
> unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
> 
-------------------------------------------------------------------------------------------
"Cette communication (y compris les pieces jointes) est reservee a l'usage exclusif du destinataire (des destinataires) et peut contenir des informations privilegiees, confidentielles, exemptees de divulgation selon la loi ou protegees par les droits d'auteur. Si vous n'etes pas un destinataire, toute utilisation, divulgation, distribution, reproduction, examen ou copie (totale ou partielle) est non-autorisee et peut etre illegale. Tout message electronique est susceptible d'alteration et son integrite ne peut etre assuree. Sanofi Pasteur decline toute responsabilite au titre de ce message s'il a ete modifie ou falsifie. Si vous n'etes pas destinataire de ce message, merci de le detruire immediatement et d'avertir l'expediteur de l'erreur de distribution et de la destruction du message. Merci.
This transmission (including any attachments) is intended solely for the use of the addressee(s) and may contain confidential information including trade secrets which are privileged, confidential, exempt from disclosure under applicable law and/or subject to copyright. If you are not an intended recipient, any use, disclosure, distribution, reproduction, review or copying (either whole or partial) is unauthorized and may be unlawful. E-mails are susceptible to alteration and their integrity cannot be guaranteed.Sanofi Pasteur shall not be liable for this e-mail if modified or falsified. If you are not the intended recipient of this e-mail, please delete it immediately from your system and notify the sender of the wrong delivery and the mail deletion. Thank you."
**********************************************************************


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