We are using WebSphere 5.1.1 and Struts 1.1 and Struts 1.2.4. IBM made this suggestion. Anyone else heard of having to resort to this? A series of tests were performed that showed that when we repeatedly stopped and started an application, we could eventually deplete the Perm Gen. The application was not exercised at all. It was simply stopped and then restarted, allowed to complete initialization and then recycled again. Other applications were also tested with the same results. However, applications making use of Struts/Spring/Hibernate tended to eat space more quickly. A ticket was opened with IBM. They responded with a couple of interesting suggestions. The first is regarding Struts. multiple restarts of an application and the buildup of objects on the Perm region. The problem is most commonly seen with struts applications and multi-classloader environments. This issue can be corrected by modifing struts. Please see the steps below to resolve this issue.
a) Obtain the source code for the struts ActionServlet class. b) At the end of method ActionServlet.destroy(), call static method org.apache.commons.beanutils.PropertyUtils.clearDescriptors(); This method clears the descriptor cache maintained, which contains bean descriptors loaded by the JVM Classloader, and hence causes the garbage collector to not collect struts classes (and their classloaders) from the heap. After, you might call method: java.beans.Introspector.flushCaches(); for multi-classloader hygeine. You can opt not to invoke flushCaches(); it does not alleviate the main symptom, either way. It ensures that the Introspector cache will always contain the current version of bean descriptor classes. The Introspector is utilized indirectly by struts, since struts uses the javabeans API. c) Recompile the ActionServlet class against the struts JAR files. d) Redeploy your application with the new struts JAR. Thanks, Jeff
