Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Message-ID: <1383028801.1130627879001.JavaMail.jira@ajax.apache.org>
Date: Sun, 30 Oct 2005 01:17:58 +0200 (CEST)
From: "Dain Sundstrom (JIRA)" <dev@geronimo.apache.org>
To: dev@geronimo.apache.org
Subject: [jira] Commented: (GERONIMO-1118) memory leak deploying web services
 caused by java.bean.Introspector.getBeanInfo()
In-Reply-To: <1926391883.1130621095939.JavaMail.jira@ajax.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/GERONIMO-1118?page=comments#action_12356294 ] 

Dain Sundstrom commented on GERONIMO-1118:
------------------------------------------

Add the cache flush code to the destroy method in org.apache.geronimo.kernel.config.MultiParentClassLoader.

> memory leak deploying web services caused by java.bean.Introspector.getBeanInfo()
> ---------------------------------------------------------------------------------
>
>          Key: GERONIMO-1118
>          URL: http://issues.apache.org/jira/browse/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 -- http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5102804.
> 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. org.apache.geronimo.samples.daytrader.client.ws.AccountDataBean), 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()
> axis-builder/src/java/org/apache/geronimo/axis/builder/HeavyweightTypeInfoBuilder.java:389
> axis-builder/src/java/org/apache/geronimo/axis/builder/LightweightTypeInfoBuilder.java:131
> service-builder/src/java/org/apache/geronimo/deployment/service/JavaBeanXmlAttributeBuilder.java:66
> 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:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira