db-ojb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danilo Tommasina <dtommas...@risksys.com>
Subject Re: ThreadLocal causing memory leak
Date Thu, 09 Jun 2005 14:56:02 GMT
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: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org


Mime
View raw message