views:

45

answers:

2

When redeploying applications in Tomcat/Glassfish/JBoss/etc it is easy to cause a classloader leak by keeping a reference to an instance from a previous classloader. Jevgeni Kabanov discusses this issue here...

http://www.zeroturnaround.com/blog/reloading-objects-classes-classloaders/

Has anybody found a good way to harness automated testing (ie: via junit) to test that redeploying your web application does not cause memory leaks? I have been wondering if perhaps using embedded Jetty would make it easy to write a junit test that re-deploys your application over and over and over again.

+1  A: 

I would consider having a look at a custom classloader for a Jetty instance, with a finalizer which tells you that it is being garbage collected, and then explicitly - through visualvm or so - tell HotSpot to garbage collect so the finalizer will be run if there is no leak.

Thorbjørn Ravn Andersen
+1  A: 

You may take a look at the memory leak detection features of Tomcat, especially since version 7.

Heri