RE: Redeploy leaks
On Sat, 2009-01-03 at 14:30 -0500, Cosio, Raul wrote: Memory leak is an advanced task. But once understood is very easy to fix them, just follow some simple rules, most common situations are: 1) Not Usually a matter of torturing yourself for some time following classloader trees, together with various static instantiations. Logging systems and Axis/jakarta-commons stuff have been the main causes of problems for me. This article was useful for me: http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded I suppose that they are very easy to fix once you work out precisely what is causing a leak, but that's a bit like saying that most bugs are very easy to fix - but thats a bit misleading isn't it, since you could spend hours/days tracking down the bug in the first place. Although its obviously nice to track down all the leaks in your app so that you could sit redeploying all day to your hearts content (I'll probably be burned at the stake for this next bit) but I do sometimes suspect that its not worth the effort and just live with having to restart your tomcat instance from time to time depending on your redeploy strategies. Mark This email has been scanned for all known viruses by the MessageLabs SkyScan service. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Redeploy leaks
Yes, you should be cooked, sauted and broiled on an open flame grin. http://community.eapps.com/showthread.php?t=153 Take a look, maybe useful On Tue, Jan 6, 2009 at 9:34 AM, Mark Hagger mark.hag...@m-spatial.comwrote: On Sat, 2009-01-03 at 14:30 -0500, Cosio, Raul wrote: Memory leak is an advanced task. But once understood is very easy to fix them, just follow some simple rules, most common situations are: 1) Not Usually a matter of torturing yourself for some time following classloader trees, together with various static instantiations. Logging systems and Axis/jakarta-commons stuff have been the main causes of problems for me. This article was useful for me: http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded I suppose that they are very easy to fix once you work out precisely what is causing a leak, but that's a bit like saying that most bugs are very easy to fix - but thats a bit misleading isn't it, since you could spend hours/days tracking down the bug in the first place. Although its obviously nice to track down all the leaks in your app so that you could sit redeploying all day to your hearts content (I'll probably be burned at the stake for this next bit) but I do sometimes suspect that its not worth the effort and just live with having to restart your tomcat instance from time to time depending on your redeploy strategies. Mark This email has been scanned for all known viruses by the MessageLabs SkyScan service. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Redeploy leaks
MGMark/Raul/Frank Yes, you should be cooked, sauted and broiled on an open flame grin. MGthis comment does not helpgrin http://community.eapps.com/showthread.php?t=153 MGgood link to illustrate PermGen settings but including class objects in sweep for recovering PermGen should be a last MGresort MGMark you are using spatial objects right??? Do they hang around in memory forever? MGConfining scope of these objects will go a long way to alleviate these problems..object falls out of scope and is marked MGfor deletion (and PermGen MarkAndSweep will be able to collect these on the next iteration) MGAre you acquiring many DB Connections or cursors and hanging on to them forever..have you considered using MG MGConnectionPools? MGThere are some really great Java tools that are available to you e.g. $JAVA_HOME/bin/jstack MGand of course jconsole which will illustrate Heap,classes,CPU and Threads MGChuck and the others will have some useful information MGRegards MGMartin Take a look, maybe useful On Tue, Jan 6, 2009 at 9:34 AM, Mark Hagger mark.hag...@m-spatial.comwrote: On Sat, 2009-01-03 at 14:30 -0500, Cosio, Raul wrote: Memory leak is an advanced task. But once understood is very easy to fix them, just follow some simple rules, most common situations are: 1) Not Usually a matter of torturing yourself for some time following classloader trees, together with various static instantiations. Logging systems and Axis/jakarta-commons stuff have been the main causes of problems for me. This article was useful for me: http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded I suppose that they are very easy to fix once you work out precisely what is causing a leak, but that's a bit like saying that most bugs are very easy to fix - but thats a bit misleading isn't it, since you could spend hours/days tracking down the bug in the first place. Although its obviously nice to track down all the leaks in your app so that you could sit redeploying all day to your hearts content (I'll probably be burned at the stake for this next bit) but I do sometimes suspect that its not worth the effort and just live with having to restart your tomcat instance from time to time depending on your redeploy strategies. Mark This email has been scanned for all known viruses by the MessageLabs SkyScan service. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org _ It’s the same Hotmail®. If by “same” you mean up to 70% faster. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_broad1_122008
RE: Redeploy leaks
From: Martin Gainty [mailto:mgai...@hotmail.com] Subject: RE: Redeploy leaks http://community.eapps.com/showthread.php?t=153 MGgood link to illustrate PermGen settings but including class objects in sweep for recovering PermGen should be a last MGresort Note that the above article applies only when the concurrent mark-sweep (CMS) GC algorithm is in effect, which is *not* the default. CMS can be manually enabled via the command line parameter: -XX:+UseConcMarkSweepGC or one of its aliases (-Xincgc, -Xconcgc). The CMS algorithm will also be invoked if UseAutoGCSelectPolicy is set and MaxGCPauseMillis is explicitly set to a value less than or equal to AutoGCSelectPauseMillis, whose default value is 5000 (the Java SE 6 release notes say 1 second, but the code says 5). Unless you have extremely stringent response time requirements, you probably don't want to enable CMS; it reduces throughput, and normal parallel GCs these days are usually fast enough not to create a noticeable hiccup. - 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 unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Redeploy leaks
Memory leak is an advanced task. But once understood is very easy to fix
them, just follow some simple rules, most common situations are: 1) Not
de-registering jdbc driver, 2) shutdown log4j after use.
To de-register jdbc driver just put this code in the contextDestroyed()
method inside a ServletContextListener in your application:
System.out.println(unloading drivers for classLoader: [ +
Integer.toHexString(getClass().getClassLoader().hashCode()) + ]);
try {
for (java.util.Enumeration e = java.sql.DriverManager.getDrivers();
e.hasMoreElements();)
{
java.sql.Driver driver = (java.sql.Driver) e.nextElement();
if (driver.getClass().getClassLoader() ==
getClass().getClassLoader())
{
java.sql.DriverManager.deregisterDriver(driver);
System.out.println(driver.getClass().getName() +
unloaded.);
}
else
System.out.println(driver.getClass().getName() + not
unloaded.);
}
} catch (Throwable e) {
System.err.println(Failed to cleanup ClassLoader for webapp);
e.printStackTrace();
}
For the log4j issue you can include also this code:
org.apache.commons.logging.LogFactory.release(Thread.currentThread().get
ContextClassLoader());
org.apache.log4j.LogManager.shutdown();
Of course there are lots of issues to handle with... you can also read:
http://tomcat.apache.org/faq/memory.html
-Original Message-
From: Adriano dos Santos Fernandes [mailto:adrian...@uol.com.br]
Sent: Viernes, 19 de Diciembre de 2008 09:20 p.m.
To: users@tomcat.apache.org
Subject: Redeploy leaks
Hi!
As I had having OutOfMemory exceptions (PermGen) when redeploying an
application, I started to verify things using Eclipse Memory Analyzer.
I've discovered some real leaks, for example caused by the Java Disposer
thread being instantiated using the Webapp classloader. After fix this,
when I redeploy the application, Memory Analyzer shows that there are no
non-weak/soft references to the undeployed classloader. But it (and the
classes allocated by it) is never garbaged collected.
I've tried different VM switches (-XX:+CMS*) and none make the
classloader be collected. Thinking about word Perm (permanent) and
some sources, I've done non-web testing and there a custom classloader
*is* garbaged collected.
So what could be the problem when running in Tomcat?
I'm using Tomcat 6.0.18, JDK 1.6.0-10 (Linux and Windows) and Apache
Wicket. I've not put any libraries in tomcat/lib, they are all on the
WEB-INF/lib. Wicket uses ThreadGlobals, but I don't think this may be a
problem, because Eclipse Memory Analyzer seems to show references from
them, but it didn't show any references in my case!
Increasing the permgen size is not something I'm looking for. I'd rather
prefer to see unused memory being deallocated.
Adriano
Notice: This e-mail message, together with any attachments, contains
information of Merck Co., Inc. (One Merck Drive, Whitehouse Station,
New Jersey, USA 08889), and/or its affiliates (which may be known
outside the United States as Merck Frosst, Merck Sharp Dohme or
MSD and in Japan, as Banyu - direct contact information for affiliates is
available at http://www.merck.com/contact/contacts.html) that may be
confidential, proprietary copyrighted and/or legally privileged. It is
intended solely for the use of the individual or entity named on this
message. If you are not the intended recipient, and have received this
message in error, please notify us immediately by reply e-mail and
then delete it from your system.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Redeploy leaks
Dear Adriano, As I had having OutOfMemory exceptions (PermGen) when redeploying an application, I started to verify things using Eclipse Memory Analyzer. I've discovered some real leaks, for example caused by the Java Disposer thread being instantiated using the Webapp classloader. After fix this, when I redeploy the application, Memory Analyzer shows that there are no non-weak/soft references to the undeployed classloader. But it (and the classes allocated by it) is never garbaged collected. I've tried different VM switches (-XX:+CMS*) and none make the classloader be collected. Thinking about word Perm (permanent) and some sources, I've done non-web testing and there a custom classloader *is* garbaged collected. So what could be the problem when running in Tomcat? I'm using Tomcat 6.0.18, JDK 1.6.0-10 (Linux and Windows) and Apache Wicket. I've not put any libraries in tomcat/lib, they are all on the WEB-INF/lib. Wicket uses ThreadGlobals, but I don't think this may be a problem, because Eclipse Memory Analyzer seems to show references from them, but it didn't show any references in my case! Here's some more discussion in that subject. http://java-monitor.com/forum/showthread.php?t=7 In particular, that thread suggests you read http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669 for some known permgen leak offenders. Perhaps some of these might give you more corners to peel at for your application? -- Kees Jan http://java-monitor.com/forum/ kjkos...@kjkoster.org 06-51838192 Human beings make life so interesting. Do you know that in a universe so full of wonders, they have managed to invent boredom. Quite astonishing... -- Terry Pratchett - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Redeploy leaks
Kees Jan Koster wrote: Dear Adriano, As I had having OutOfMemory exceptions (PermGen) when redeploying an application, I started to verify things using Eclipse Memory Analyzer. I've discovered some real leaks, for example caused by the Java Disposer thread being instantiated using the Webapp classloader. After fix this, when I redeploy the application, Memory Analyzer shows that there are no non-weak/soft references to the undeployed classloader. But it (and the classes allocated by it) is never garbaged collected. I've tried different VM switches (-XX:+CMS*) and none make the classloader be collected. Thinking about word Perm (permanent) and some sources, I've done non-web testing and there a custom classloader *is* garbaged collected. So what could be the problem when running in Tomcat? I'm using Tomcat 6.0.18, JDK 1.6.0-10 (Linux and Windows) and Apache Wicket. I've not put any libraries in tomcat/lib, they are all on the WEB-INF/lib. Wicket uses ThreadGlobals, but I don't think this may be a problem, because Eclipse Memory Analyzer seems to show references from them, but it didn't show any references in my case! Here's some more discussion in that subject. http://java-monitor.com/forum/showthread.php?t=7 In particular, that thread suggests you read http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669 for some known permgen leak offenders. Perhaps some of these might give you more corners to peel at for your application? After reading this again (I had already read the spring page), I started done multiple reloads and checks. I don't believe that a Tomcat thread holds my classloader because Eclipse MAT didn't show them, so in my tests I didn't even tried to request any page, just reload the app from the manager application. It may be just how the permgen works. After some reloads, older classloaders was collected. :-) So this seems not as real memory leaks. Thanks, Adriano - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
