@Chuck -- The moment I remove context xml (xyz##001.xml) file, tomcat automagically removes the corresponding dir from webapps. So that's not an issue.
In my log file i see the following message INFO | jvm 1 | 2011/07/19 16:11:07 | Jul 19, 2011 4:11:07 PM org.apache.catalina.startup.HostConfig checkResources INFO | jvm 1 | 2011/07/19 16:11:07 | INFO: Undeploying context [##001] INFO | jvm 1 | 2011/07/19 16:11:07 | Jul 19, 2011 4:11:07 PM org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc INFO | jvm 1 | 2011/07/19 16:11:07 | SEVERE: The web application [##001] registered the JDBC driver [oracle.jdbc.driver.OracleDriver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered. Currently i am using commons-dbcp connection pooling. I will switch to Tomcat-JDBC connection pool and see if memory leak message goes away or not. I will update this thread with my findings. Thanks all you guys with your suggestion... On Tue, Jul 19, 2011 at 5:33 PM, Caldarale, Charles R <chuck.caldar...@unisys.com> wrote: >> From: Monsieur fsfu [mailto:monsieurf...@gmail.com] >> Subject: Tomcat 7 parallel deployment and PermGen Heap Space > >> Now if i remove the old war file (xyz##001.war) by removing >> xyz##001.xml ($catalina_home/conf/Catalina/locahost/xyz##001.xml), >> PermGen space doesn't come down. > > First, verify that the first instance really has been undeployed. > > Second, unless you insure that at least two full GCs happen after undeploying > the first .war file, class unloading will not occur. Even then, it's a bit > of guess whether or not the JVM will choose to unload classes in the absence > of pressure on PermGen. > > Regardless, as others suggested, running some heap analysis tool will find > out if you've got a leak built into your webapp, or if the JVM has simply > decided not to bother with class unloading yet. > > - 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
