RE: Memory leaks on webapp redeploy
I'm running on 6, I've just in the prototyping stage so using an early release version is fine. I did notice that in 6 anyway (haven't looked at 5.5) that the releaseResources() calls this.. // Clear the classloader reference in common-logging org.apache.juli.logging.LogFactory.release(this); Which looks very similar to commons logging but has juli in the package instead. Probably is the same thing, just under another name maybe. Even the comment says common-logging. -Original Message- From: Rémy Maucherat [mailto:[EMAIL PROTECTED] Sent: 28 November 2006 23:37 To: Tomcat Users List Subject: Re: Memory leaks on webapp redeploy On 11/28/06, Mike Quilleash [EMAIL PROTECTED] wrote: As a brief aside I found the following code in the WebAppClassLoader.releaseResources() of Tomcat 6, so it looks like some of the well-known caches are being cleared out by Tomcat itself. Are you using 5.5 or 6.0 ? If you're using 5.5, then you should be looking at the 5.5 source. At the end of the clearReferences method in 5.5, the commons-logging reference to the classloader is cleared again (along with other leak friendly static fields) so no leak can occur because of usage of logging in this method. Investigation has shown there was no leaking related to logging (and actually no reference being kept anywhere). Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail is bound by the terms and conditions described at http://www.subexazure.com/mail-disclaimer.html - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks on webapp redeploy
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 [EMAIL PROTECTED] To: Tomcat Users List users@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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks on webapp redeploy
[EMAIL PROTECTED] 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 [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
RE: Memory leaks on webapp redeploy
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks on webapp redeploy
-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks on webapp redeploy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Remy, [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory leaks on webapp redeploy
From: Christopher Schultz [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks on webapp redeploy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, Caldarale, Charles R wrote: From: Christopher Schultz [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory leaks on webapp redeploy
From: Christopher Schultz [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory leaks on webapp redeploy
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks on webapp redeploy
-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory leaks on webapp redeploy
From: Christopher Schultz [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory leaks on webapp redeploy
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks on webapp redeploy
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 [EMAIL PROTECTED] To: Tomcat Users List users@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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks on webapp redeploy
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 [EMAIL PROTECTED] To: Tomcat Users List users@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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- BR, Anjan Bacchu Summit Information Systems - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks on webapp redeploy
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: [EMAIL PROTECTED] To: users@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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory leaks on webapp redeploy
2006 16:43 To: Tomcat Users List Subject: RE: Memory leaks on webapp redeploy From: Christopher Schultz [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail is bound by the terms and conditions described at http://www.subexazure.com/mail-disclaimer.html - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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. - -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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory leaks on webapp redeploy
From: Mike Quilleash [mailto:[EMAIL PROTECTED] Subject: RE: Memory leaks on webapp redeploy Looks like during the WebappClassLoader cleanup the logging is being reinitialised. You may well have found the problem. Must be some context-specific logging going on after contextDestroyed() is called. What happens if you put a call to LogFactory.releaseAll() in contextInitialized() rather than contextDestroyed()? This should remove all traces of the prior instance. - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks on webapp redeploy
- Original Message - From: Christopher Schultz [EMAIL PROTECTED] To: Tomcat Users List users@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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks on webapp redeploy
On 11/28/06, Mike Quilleash [EMAIL PROTECTED] wrote: As a brief aside I found the following code in the WebAppClassLoader.releaseResources() of Tomcat 6, so it looks like some of the well-known caches are being cleared out by Tomcat itself. Are you using 5.5 or 6.0 ? If you're using 5.5, then you should be looking at the 5.5 source. At the end of the clearReferences method in 5.5, the commons-logging reference to the classloader is cleared again (along with other leak friendly static fields) so no leak can occur because of usage of logging in this method. Investigation has shown there was no leaking related to logging (and actually no reference being kept anywhere). Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- BR, Anjan Bacchu Summit Information Systems
Re: Memory leaks on webapp redeploy
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 [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
