Author: markt Date: Fri Feb 12 17:49:49 2010 New Revision: 909525 URL: http://svn.apache.org/viewvc?rev=909525&view=rev Log: 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)
Modified: tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java Modified: tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java?rev=909525&r1=909524&r2=909525&view=diff ============================================================================== --- tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java (original) +++ tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java Fri Feb 12 17:49:49 2010 @@ -1782,6 +1782,10 @@ } // 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 @@ 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); --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org