From 660fd1d3a4db4ae7ec8f9b6803c03a4dde2a4422 Mon Sep 17 00:00:00 2001 From: markt Date: Fri, 12 Feb 2010 17:49:49 +0000 Subject: [PATCH] Looks like the ResourceBundle leaks are triggered by a GC bug - only seems to affect Sun JVMs. The fix is also Sun specific so only log a debug message if the internal field can't be found on a non-Sun JVM (it isn't there for IBM for example) git-svn-id: https://svn.apache.org/repos/asf/tomcat/trunk@909525 13f79535-47bb-0310-9956-ffa450edef68 --- java/org/apache/catalina/loader/WebappClassLoader.java | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/java/org/apache/catalina/loader/WebappClassLoader.java b/java/org/apache/catalina/loader/WebappClassLoader.java index 4e98b1bfa..0736f5c52 100644 --- a/java/org/apache/catalina/loader/WebappClassLoader.java +++ b/java/org/apache/catalina/loader/WebappClassLoader.java @@ -1782,6 +1782,10 @@ public class WebappClassLoader } // Clear the resource bundle cache + // This shouldn't be necessary, the cache uses weak references but + // it has caused leaks. Oddly, using the leak detection code in + // standard host allows the class loader to be GC'd. This has been seen + // on Sun but not IBM JREs. Maybe a bug in Sun's GC impl? clearReferencesResourceBundles(); // Clear the classloader reference in the VM's bean introspector @@ -2395,8 +2399,13 @@ public class WebappClassLoader log.error(sm.getString( "webappClassLoader.clearReferencesResourceBundlesFail"), e); } catch (NoSuchFieldException e) { - log.error(sm.getString( - "webappClassLoader.clearReferencesResourceBundlesFail"), e); + if (System.getProperty("java.vendor").startsWith("Sun")) { + log.error(sm.getString( + "webappClassLoader.clearReferencesResourceBundlesFail"), e); + } else { + log.debug(sm.getString( + "webappClassLoader.clearReferencesResourceBundlesFail"), e); + } } catch (IllegalArgumentException e) { log.error(sm.getString( "webappClassLoader.clearReferencesResourceBundlesFail"), e); -- 2.11.0