Solving a PermGen issue on redeploy with Jetty 7
Asked Answered
O

2

6

After a couple of days of debugging I have managed to have a medium-to-large web application redeploy successfully on Tomcat 6.0.32 without any PermGen leaks. I saw the PermGen drop after it filled, and the classloaders were garbage collected.

After much rejoicing I tried to make the application redeploy without leaks on our development environment, which is composed of Maven and the Jetty plugin.

Unfortunately I seem to have hit a server limitation, as illustrated by the below screenshot

Yourkit snapshot http://img811.imageshack.us/img811/7320/jettyclassloaderbeanelr.png

Jetty request threads have a strong reference to a BeanElResolver which in turns has a strong reference to multiple classes from my webapp.

I have found no reference on how to flush this information.

How can I remove this final PermGen leak from my application?


Update:

I've done the following to fix the problem, with no luck:

  • updated to the Latest version of the Jetty Plugin ( both 7.4.5 and 8.0.0.M3 )
  • used the CMS collector : -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled

Update 2:

Ogren answered 25/7, 2011 at 14:59 Comment(5)
I don't understand your wording. What do you mean with PermGen-Leak? Did you try to give soem GC related flags to the VM like: -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled ? Do you expect a running web app to be completely collected when no connection/session is up?Variolous
Angel: by default, your servlet container leaks classloaders on each redeploy. Class definitions are allocated out of the permanent generation, so you will get a PermGen leak. I'm impressed the OP managed to circumvent this problem with Tomcat 6 and no flags.Hulton
Robert: please consider telling us more about what you did to fix the leak in Tomcat 6! I'd love to know what you did. Wiki, perhaps?Hulton
@Angel: I don't use the CMS garbage collector, so I don't need to specify those flags. And with PermGen leak I mean that on undeploy the old classloader instance remains pinned in memory, not allowing the classes to be garbage collected.Ogren
That is why I suggested to use the other GC, the standard GC does not collect permgen at all, IIRC.Variolous
O
2

This is a actual bug in the EL implementation which is worked around in the latest Jetty versions.

Version 7.5.0, once released, will contain the fix.

Ogren answered 29/7, 2011 at 8:32 Comment(0)
U
0

Not a direct answer to your question, but you might consider using JRebel in dev. With JRebel, you mostly don't have to redeploy, thus avoiding both the permgen leaks and the wasted time of a redeploy. It's been working extremely well for me.

Utile answered 25/7, 2011 at 16:5 Comment(1)
I already use JRebel, but a) I sometimes have to restart, b) not everyone in my team does so I need to find a better solution for them as well.Ogren

© 2022 - 2024 — McMap. All rights reserved.