Hi Martin, thanks for the quick reply. >> we are observing memory leaks in our web-application when redeploying in a >> web-context
> Just a quick first though before reading your post in detail... LOL, I knew, I had to put the second phrase of my previous e-mail at the first position :) The only text that I can see in the Tomcat 5.5.9 release notes is the following: ================================================================ Web application reloading and static fields in shared libraries: ================================================================ Some shared libraries (many are part of the JDK) keep references to objects instantiated by the web application. To avoid class loading related problems (ClassCastExceptions, messages indicating that the classloader is stopped, etc.), the shared libraries state should be reinitialized. Something which might help is to avoid putting classes which would be referenced by a shared static field in the web application classloader, and putting them in the shared classloader instead (JARs should be put in the "lib" folder, and classes should be put in the "classes" folder). --------------- The above mentioned situation is not my case, before tomcat 4.1.31 and in early tomcat 5.0.x and 5.5.x versions there were ClassLoader issues that prevented the WeappClassLoader to be garbage collected on application shutdown, however the newer versions seems to work correctly and they also manage to garbage the ClassLoader including singletons and static fields. Applying the workaround (override of the PersistenceBrokerFactoryDefaultImpl) *our application is now able to be completely garbage collected at shutdown using the 'apache tomcat manager web application'*. this was tested on tomcat 5.5.9 on JDK 1.5.0_02, JVM switches: -Xmx128m -XX:PermSize=128M -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+TraceClassUnloading -XX:+ClassUnloading -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -Dcom.sun.management.jmxremote=true The unloading of classes and state of the PermGen was beeing observed using the JConsole delivered with JDK 1.5 I still did not have the time to test the other platforms, but I guess that 'Thread recycling' is a common case within web-servers and the issue may apply to potentially any J2EE compliant web-container, if the cause is really what I mentioned in my previous mail. Odd, is the fact the garbage collection is not working if I use the netbeans profiler... but I am not going to debug this one :) Examinig a bit better the code of PersistenceBrokerThreadMapping I see that an HashMap is used where I would expect to see a WeakHashMap and a WeakHashMap is used where probably an HashSet would do... I'll try out some combinations and I'll let you know if I find out something useful. bye danilo > Danilo Tommasina (No Signature) wrote: > >> we are observing memory leaks in our web-application when redeploying >> in a web-context > > > Just a quick first though before reading your post in detail... > > Do you know that the Servlet reloading functionality in > Apache Tomcat "Manager Web Application" is not meant for production use, > and that it is a well-documented 'feature' that the ClassLoader cannot > re-use memory and that you _will_ get memory leaks when using this feature > (ie pushing RELOAD of a webapp in the manager app -- see Tomcat release > notes > for docs about this). > > Howerver, since you also mention JBoss and J2EE redeployment I guess > we won't get away just as easy as "RTM!"? ;) > > Regards, > Martin > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
