Looks like the ResourceBundle leaks are triggered by a GC bug - only seems to affect...

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

diff --git a/java/org/apache/catalina/loader/WebappClassLoader.java b/java/org/apache/catalina/loader/WebappClassLoader.java
index 4e98b1b..0736f5c 100644 (file)
--- 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);