• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Memory Leak after repeat deploy and undeploy

 
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I put all jar files in the lib of Tomcat and there are no jars in my web app. After repeated deploy and undeploy with Tomcat Manager, memory leak happened.

How to get rid of this issue?
 
Jianping Wang
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Forget to mention: I use Tomcat 6.0.20
 
Sheriff
Posts: 13411
Firefox Browser VI Editor Redhat
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In short, you can't.

The memory that's 'leaking' is the perm-gen section.
This is where interned strings, constants, and in this case, class definitions are stored.
When you load a Java class the definition is written to a permanent section of the JVM's memory block and is never unloaded.

When you reload an application, Tomcat's custom classloaders re-load every class used by that application; not just the one in jar libs but also the classes that are dynmically generated from your JSPs. Since these are never purged, constant reloading of an application will cause the perm-gen sector to keep growing.

The best answer is to clean restart tomcat from time to time.
You can buy more time by allocating more ram to the perm-gen sector with this switch:
-XX:MaxPermSize=600M

But this only buys you time. If you're reloading apps all the time, you'll need to perform a clean start of Tomcat once in a while.
 
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jianping Wang wrote:Forget to mention: I use Tomcat 6.0.20



One thing you should definitely try is upgrading to 6.0.26. There has been a fair amount of recent work targeted at memory leaks...
 
JavaMonitor Support
Posts: 251
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dear Jianping,

Upgrade to the latest Tomcat and enable its permgen leak detector: http://java-monitor.com/forum/showthread.php?t=818

Also, put the JAR files back into the WAR. Giving them to Tomcat makes it harder to manage their versions and impossible for Tomcat to unload them.

Kees Jan
 
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Kees Jan Koster wrote:
Also, put the JAR files back into the WAR. Giving them to Tomcat makes it harder to manage their versions and impossible for Tomcat to unload them.



You also risk massive data corruption and system failure. A Jar in the TOMCAT lib directory is on the classpath of every deployed application and therefore its resources are shared with each and every thread in each and every deployed webapp. If the jar wasn't designed for this kind of multi-threaded use, there's a possibility that the apps will corrupt the jar class resources.

Certain types of jars should be stored in TOMCAT/lib, such as most database driver jars. They're designed to be shared, and in fact, will better co-ordinate resources when placed in the common library directory. But a lot of jars aren't. When in doubt, don't.
 
Jianping Wang
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You are absolutely right!!!
I put jar in web app and the leak issue disappeared after change to Tomcat 6.0.26
 
Ranch Hand
Posts: 145
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I upgraded to 6.0.29 and my Tomcat still gets the PermGen when it reaches ~111MB
I've set this w/o any effect in system environment variables and eclipse launch configuration environment:
CATALINA_OPTS -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -XX:MaxPermSize=512m -Xms512m -Xmx512m

Seems that every time i clean-build the project, triggering an autopublish and context reload, and after i 'refresh' the app in the browser with a button calling close() on application, Tomcat loads the app in memory, but it doesn't clean the old, so each time i do this it goes up another 15MB. At about 112MB i get a PermGen error. How to fix this please?

I also had this (is that so dire that it leaves behind 15MB every time, as much as the whole app?):

Jul 27, 2010 6:42:57 AM org.apache.catalina.core.StandardContext reload
INFO: Reloading this Context has started
Jul 27, 2010 6:42:57 AM org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc
SEVERE: The web application [/realloto] registered the JBDC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
Jul 27, 2010 6:42:57 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/realloto] appears to have started a thread named [Timer-0] but has failed to stop it. This is very likely to create a memory leak.
Jul 27, 2010 6:42:57 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/realloto] appears to have started a thread named [com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0] but has failed to stop it. This is very likely to create a memory leak.
Jul 27, 2010 6:42:57 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/realloto] appears to have started a thread named [com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1] but has failed to stop it. This is very likely to create a memory leak.
Jul 27, 2010 6:42:57 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/realloto] appears to have started a thread named [com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2] but has failed to stop it. This is very likely to create a memory leak.
Jul 27, 2010 6:42:57 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/realloto] appears to have started a thread named [MySQL Statement Cancellation Timer] but has failed to stop it. This is very likely to create a memory leak.

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is very common in Windows environment but there is a solution :

Open context.xml from /tomcat/conf folder and modify the context to match this :

<Context antiJarLocking="true" antiResourceLocking="true">


http://stackoverflow.com/questions/14873219/cannot-undeploy-a-web-app-completely-in-tomcat-7
 
reply
    Bookmark Topic Watch Topic
  • New Topic