WebappClassLoader.clearReferences removes root Java Logger handlers
Hello!
I am using apache-tomcat-6.0.26 with Tanuki Wrapper.
In this particular setup, Juli is not used (no
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager) and
java.util.logging.LogManager returns standard Java SE instance.
org.apache.catalina.loader.WebappClassLoader.clearReferences() calls Juli
org.apache.juli.logging.LogFactory.release() which in turn
issues
LogManager.getLogManager().reset();
For Juli this, I suppose, means return to pristine state before any
changes have been done.
But for Java SE LogManager this REMOVES any handlers in root classloader.
This causes all logging to stop after such event as web application
redeployment.
I propose following change to Juli org.apache.juli.logging.LogFactory:
--- LogFactory.orig
+++ LogFactory.java
@@ -328,9 +328,11 @@
*/
public static void release(
@SuppressWarnings("unused") ClassLoader classLoader) {
+if (LogManager.getLogManager() instanceof ClassLoaderLogManager) {
// JULI's log manager looks at the current classLoader
LogManager.getLogManager().reset();
+ }
}
P.S. If needed, I can create bug in bugzilla.
With kindest personal regards,
Ruslan Gainutdinov
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
In cluster, when using DeltaManager memory leak can occur
Tested on apache-tomcat-6.0.29 running under jdk 1.6.0_18. When DeltaManager is instantiated and assigned in StandardContext.start(), is it done AFTER StandardContext.bindThreads(). DeltaManager, in turn, during initalization, asks for sessions in other nodes, and this may result in creating threads ThreadPoolExecutor in tribes. These threads created with contextClassLoader set to current webapplication WebAppClassLoader. This results in memory leak and error message during redeployment in tomcat log: 09/09/2010 14:46:19 S - - WebappClassLoader.clearReferencesThreads: The web application [/creditdev] appears to have started a thread named [pool-1-thread-1] but has failed to stop it. This is very likely to create a memory leak. Stacktrace: at java.util.concurrent.ThreadPoolExecutor.addThread(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.addIfUnderCorePoolSize(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.execute(Unknown Source) at org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor.addToQueue(MessageDispatch15Interceptor.java:67) at org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor.sendMessage(MessageDispatchInterceptor.java:68) at org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage(ChannelInterceptorBase.java:75) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.sendMessage(TcpFailureDetector.java:87) at org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage(ChannelInterceptorBase.java:75) at org.apache.catalina.tribes.group.GroupChannel.send(GroupChannel.java:216) at org.apache.catalina.tribes.group.GroupChannel.send(GroupChannel.java:175) at org.apache.catalina.ha.tcp.SimpleTcpCluster.send(SimpleTcpCluster.java:813) at org.apache.catalina.ha.session.DeltaManager.getAllClusterSessions(DeltaManager.java:959) at org.apache.catalina.ha.session.DeltaManager.start(DeltaManager.java:930) at org.apache.catalina.core.ContainerBase.setManager(ContainerBase.java:438) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4559) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:546) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:637) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:563) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:498) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) at org.apache.catalina.core.StandardHost.start(StandardHost.java:785) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:445) at org.apache.catalina.core.StandardService.start(StandardService.java:519) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:581) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.tanukisoftware.wrapper.WrapperStartStopApp.run(WrapperStartStopApp.java:243) at java.lang.Thread.run(Unknown Source) Proposed solution - implement java.util.concurrent.ThreadFactory in MessageDispatch15Interceptor and pass instance on ThreadPoolExecutor executor creation. This instance must call setContextClassLoader(null) in newThread() overriden method. With kindest personal regards, Ruslan Gainutdinov - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: In cluster, when using DeltaManager memory leak can occur
> Proposed solution - implement java.util.concurrent.ThreadFactory in > MessageDispatch15Interceptor > and pass instance on ThreadPoolExecutor executor creation. I`ve created patch for proposed solution. http://huksley.sdot.ru/wp-content/uploads/2010/09/tomcat-fix-memory-leak-deltamanager.zip With kindest personal regards, Ruslan Gainutdinov - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Patch for better support of Unified EL 2.2
Please review this patch for inclusion in trunk. Basically it replaces direct calls to org.apache.el.ExpressionFactoryImpl to ExpressionFactory.newInstance(). And Tomcat implementation of el-api is modified to add ExpressionFactory.newInstance() method which do it old way. With this patch, is it easy to globally switch to different implementation of Expression Language. For instance for JSF2, you don`t need to specify com.sun.faces.expressionFactory com.sun.el.ExpressionFactoryImpl which is awkward and ties to specific implementation. More info: http://huksley.sdot.ru/141/tomcat-and-unified-e22.html With kindest personal regards, Ruslan Gainutdinov - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Patch for better support of Unified EL 2.2
Created bug 48941. I would like it to be integrated into Tomcat 6, if possible. Proposed changes are light, IMHO. With kindest personal regards, Ruslan Gainutdinov On Thu, Mar 18, 2010 at 4:18 PM, Konstantin Kolinko wrote: > 2010/3/18 Ruslan Gainutdinov : >> Please review this patch for inclusion in trunk. > > Your attachment is lost. > Please create a Bugzilla entry for Tomcat 7 and attach it there, > though I cannot comment on whether it will be applied or not. > > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
