Utkarsh, On Jul 28, 2017 2:10 PM, "Utkarsh Dave" <utkarshkd...@gmail.com> wrote:
Hi Users, I am running Tomcat 7.0.77 on a linux server with openJDK 1.7.0.131 I am working on an issue where within 2-3 days Tomcat goes out of memory because of java.lang.OutOfMemoryError: PermGen space . After monitoring permgen via jconsole and checking catalina logs we noticed the information messages Jul 12, 2017 11:27:02 AM org.apache.catalina.startup.HostConfig reload INFO: Reloading context [/abc] Jul 12, 2017 11:27:02 AM org.apache.catalina.core.StandardContext reload INFO: Reloading Context with name [/abc] has started I see web.xml within webapp/abc/WEB-INF has the same time stamp of that of the information message. This makes me deduce that since Tomcat sees the new time stamp on web.xml, it reloads this web-app. I, however, do not see the date/time stamp change on webapp/abc folder. Meaning the web application does not get deployed but it getting reloaded into Tomcat. Do you have set "context reloadable=true" somewhere in your app context? That happens when you set that. But as far as I know, that process should clear all old references first and then reload all classes and libraries. Definitely some of the old references remains in the memory which is gradually filling Permgen. How can i debug this further i find who is responsible in changing web.xml (If my analysis above is correct). Should adding a stack trace within tomcat code (from where "INFO: Reloading context ") will help? Windows have filesystem audit. I believe Linux will have something equivalent. Or if there is another option please share with me. Thanks for your help in advance. -Utkarsh Dave If you are interested to know what is filling Permgen...then: First, look inside the Permgen and see what is growing over time. JMAP can help you. Use jmap -permstat command to gather Permgen data - every 12hrs. Then compare them. visualvm is another free and very nice option to look inside Permgen. You can also check heap dumps with Eclipse MAT and look for duplicate classes. In your case, I suspect there will be multiple classloaders and some of them will be inactive. Find out what is preventing those inactive classloaders from garbage collected. You can use MAT's "shortest path to gc roots" option to do that. They are the problem. yourkit can also help you to find that out easily...jprofiler fans, please don't get offended. ;) Thanks! Suvendu
