geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevan Miller (JIRA)" <>
Subject [jira] Created: (GERONIMO-1118) memory leak deploying web services caused by java.bean.Introspector.getBeanInfo()
Date Sat, 29 Oct 2005 21:24:55 GMT
memory leak deploying web services caused by java.bean.Introspector.getBeanInfo()

         Key: GERONIMO-1118
     Project: Geronimo
        Type: Bug
  Components: webservices  
    Versions: 1.0    
 Environment: Sun JDK 1.4.2/Win XP
    Reporter: Kevan Miller

If you deploy and undeploy DayTrader several times, your server will run out of Permanent
Generation space. I've tracked down a problem which is caused by java.bean.Introspector (there
may be other problems, but it's hard to tell until this problem is fixed). The basic problem
is described here --

To summarize, the static method java.bean.Introspector.getBeanInfo(Class) computes a BeanInfo
object to describe the given Class. The computed BeanInfo data is cached in a WeakHashMap
called "beanInfoCache". There's one fatal flaw in this approach. There's nothing "weak" at
all about beanInfoCache. The key for the Map is the Class object. The value object is the
BeanInfo data. Unfortunately, the BeanInfo data strongly references the Class. This strong
reference will prevent the Class from being identified as available for GC via the WeakHashMap.

Since java.bean.Introspector is loaded by the system class loader (and is thus a GC root),
this means that Bean classes (e.g.,
their MultiParentClassLoader, and all classes loaded by the MultiParentClassLoader will be
kept alive until you kill your server...

Luckily (or because of this problem?), Introspector also has flushCaches() and flushFromCaches(Class)
methods which perform predictable functions. Several projects, including Tomcat and Spring,
use these methods to prevent Introspector from causing memory leaks in their environments.

Geronimo has the following usages of getBeanInfo()


A non-scientific search (e.g. I don't have all the source), showed calls to Introspector.getBeanInfo()
by the following projects:

axis, cglib, commons-collections, tomcat (but calls flushCache), log4j 

I've thought of the following options for fixing this problem (alternative proposals welcome):

1. Follow all calls to getBeanInfo(Class) with a flushFromCaches(Class). This seems fragile
and impractical (we can't insure that other projects/apps follow this rule). 
2. Force java.Bean.Introspector to be loaded by MultiParentClassLoader. This would prevent
the Introspector class from being a GC root. Would work, but is counter to the current class
loader implementation...
3. Call Introspector.flushCaches() at appropriate times (i.e. when a ClassLoader is going
out of scope -- when a GBean is stopped?). I need a little help here in knowing when/where
this should be... Although this is a bit heavy-handed, it seems like a safe approach.
4. (just thought of this one). Instead of calling flushCaches() as described in 3, we could
instead loop through all classes loaded by the appropriate MultiParentClassLoaders and call
flushFromCaches(Class) (or a subset of the classes). This would work, but doesn't seem necessary.
I doubt we have very much caching going on...

I'll work on 3 and see how things improve...

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message