Glassfish v3 and v3.0.1 leak memory when repeatedly redeploying the same
The actual use case in our project is that we work with Eclipse and the
Glassfish plugin so that our application get redeployed automatically whenever
we save a file. After a couple of edit-save-redeploy cycles, Glassfish throws an
OutOfMemoryError (either with heap or PermGenSpace) so we have to kill the
Glassfish process and/or restart Eclipse to continue working which is rather
This problem first occurred on Glassfish v3 (full profile). Our application uses
JPA (Hibernate), EJBs (Local Stateless Session Beans), Wicket and CDI injections
both in the EJB and web layers.
Taking heap dumps with jvisualvm after a number of redeployments, I could
observe multiple copies of our application classes loaded by different instances
of WebappClassLoader. Some of these had a GC root deep down in the Felix module
storage of the weld-osgi-bundle.
Having a look at the Glassfish and Weld sources, I noticed that the problem was
indeed caused by Weld, not by Glassfish: they registered a "singleton per
classloader" of their Container class and forgot to unregister it on undeployment.
This bug is fixed in Weld 1.0.1, so then I checked whether a more recent
Glassfish build would contain this version of Weld (and not the buggy 1.0.0.SP4
version from Glassfish v3).
At that time, Glassfish 3.0.1b21 was the most recent promoted build, and it
contained Weld 1.0.1.SP3, so I gave it a try, and the problem was gone, or at
least I could redeploy my application a much larger number of times without any
I was looking forward to using the official 3.0.1 release instead of the
promoted build, but unfortunately this release has even more drastic memory
leaks on repeated redeployment of our application.
So far, I have no clue what the cause might be, I don't think it is Weld this
time. Heap dumps do not give much indication either; this time I can see
multiple instances of WebAppClassLoader most of which do not have a GC root at
all, and the remaining ones have a GC root in (Timer)Thread.contextClassLoader.
I'll try to isolate the problem and hopefully attach a small web app to this
issue to make it reproducible.
We are using Sun JDK 1.6.0_20 on Ubuntu 10.04 and Windows XP.