tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cosio, Raul" <jose_raul_co...@merck.com>
Subject RE: Redeploy leaks
Date Sat, 03 Jan 2009 19:30:17 GMT
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:adrianosf@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message