This is a known issue. I agree that it would be nice to do something with it. Ideas are welcome. The only one I have at the moment is to make ClassInfo an instance and inject it into the SQL mapper configuration. I've done similar things to eliminate static classes in the framework.
You can call ClassInfo.setCacheEnabled(false); to stop it from caching classes. Clinton On Thu, Apr 1, 2010 at 9:33 PM, Derek Scherger <de...@echologic.com> wrote: > I ran into an "interesting" issue with sqlmaps today. > > I've been trying to get a webapp into a state where it can be reloaded > repeatedly without eventually failing but this turns out to be almost > impossible (see http://www.szegedi.org/articles/memleak.html for an > entertaining write up). The JDK has various places that can hold references > to classes loaded by a webapp classloader, which prevents the webapp > classloader from being garbage collected (see > http://www.docjar.com/docs/api/sun/net/www/http/HttpClient.html and > http://www.docjar.com/html/api/sun/net/www/http/KeepAliveCache.java.htmlfor > examples). Eventually the (Sun) JVM runs out of PermGen space, throws an > OutOfMemoryError and all is lost. > > Tomcat 5.5 tries to clean up various things in the clearReferences method > of its WebappClassLoader, like deregistering jdbc drivers, clearing various > IntrospectionUtils caches, releasing the commons logging LogFactory, etc. > but there are so many different things that hold references it is fighting a > losing battle. > > In trying to rearrange various jars in the app I'm working with to avoid > holding references from outside the webapp classloader to classes inside the > webapp classloader I noticed that sqlmaps has similar issues. The ClassInfo > CLASS_INFO_MAP holds onto a static map keyed by class. If the sqlmap jars > are loaded from outside the webapp classloader (in Tomcat's common or shared > libs) this map can hold references to classes loaded by the webapp > classloader. These references keep the webapp classloader live in the eye of > the garbage collector and it will never be reclaimed. This keeps all the > classes loaded by the webapp classloader live and eats up PermGen space > fairly quickly. > > Here's another good link that notes problems with sqlmaps as well > http://www.java-community.de/archives/140-Memory-leaks-et-alii.html > > There are so many other places that do similar things that fixing sqlmaps > probably won't help the situation much, but it sure can't hurt. It would be > nice if sqlmaps could be changed to use weak references to the cached > reflection information so that it isn't the reason a webapp classloader > can't be reclaimed by the garbage collector. > > Cheers, > Derek > >
