[jira] [Comment Edited] (LOG4J2-1259) Log4j threads are leaking on Tomcat shutdown
[
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15894974#comment-15894974
]
Veit Guna edited comment on LOG4J2-1259 at 3/3/17 8:33 PM:
---
I just ran into the same problem using 2.8.1.
Apache Tomcat/8.0.20, jdk 1.8.0_66-b18, Windows 7.
I've added the log4j-web.jar, switched to servlet spec 3.0 in my web.xml and
I'm using Spring in my web application.
I've added an AsyncAppender in front of my SmtpAppender. Starting the webapp
and directly stopping it leads to:
{code}
...
2017-03-03 21:17:56,049 localhost-startStop-2 TRACE Reregistering MBeans after
reconfigure.
Selector=org.apache.logging.log4j.core.selector.ClassLoaderContextSelector@33d1ef79
2017-03-03 21:17:56,049 localhost-startStop-2 TRACE Reregistering context
(1/1): '37b00782' org.apache.logging.log4j.core.LoggerContext@28b6cf75
2017-03-03 21:17:56,049 localhost-startStop-2 TRACE Unregistering but no MBeans
found matching 'org.apache.logging.log4j2:type=37b00782'
2017-03-03 21:17:56,050 localhost-startStop-2 TRACE Unregistering but no MBeans
found matching 'org.apache.logging.log4j2:type=37b00782,component=StatusLogger'
2017-03-03 21:17:56,050 localhost-startStop-2 TRACE Unregistering but no MBeans
found matching
'org.apache.logging.log4j2:type=37b00782,component=ContextSelector'
2017-03-03 21:17:56,050 localhost-startStop-2 TRACE Unregistering but no MBeans
found matching
'org.apache.logging.log4j2:type=37b00782,component=Loggers,name=*'
2017-03-03 21:17:56,051 localhost-startStop-2 TRACE Unregistering but no MBeans
found matching
'org.apache.logging.log4j2:type=37b00782,component=Appenders,name=*'
2017-03-03 21:17:56,051 localhost-startStop-2 TRACE Unregistering but no MBeans
found matching
'org.apache.logging.log4j2:type=37b00782,component=AsyncAppenders,name=*'
2017-03-03 21:17:56,051 localhost-startStop-2 TRACE Unregistering but no MBeans
found matching
'org.apache.logging.log4j2:type=37b00782,component=AsyncLoggerRingBuffer'
2017-03-03 21:17:56,051 localhost-startStop-2 TRACE Unregistering but no MBeans
found matching
'org.apache.logging.log4j2:type=37b00782,component=Loggers,name=*,subtype=RingBuffer'
2017-03-03 21:17:56,052 localhost-startStop-2 DEBUG Registering MBean
org.apache.logging.log4j2:type=37b00782
2017-03-03 21:17:56,055 localhost-startStop-2 DEBUG Registering MBean
org.apache.logging.log4j2:type=37b00782,component=StatusLogger
2017-03-03 21:17:56,056 localhost-startStop-2 DEBUG Registering MBean
org.apache.logging.log4j2:type=37b00782,component=ContextSelector
2017-03-03 21:17:56,056 localhost-startStop-2 DEBUG Registering MBean
org.apache.logging.log4j2:type=37b00782,component=Loggers,name=
2017-03-03 21:17:56,057 localhost-startStop-2 DEBUG Registering MBean
org.apache.logging.log4j2:type=37b00782,component=Loggers,name=org.hibernate.SQL
2017-03-03 21:17:56,058 localhost-startStop-2 DEBUG Registering MBean
org.apache.logging.log4j2:type=37b00782,component=Loggers,name=org.springframework.transaction
2017-03-03 21:17:56,059 localhost-startStop-2 DEBUG Registering MBean
org.apache.logging.log4j2:type=37b00782,component=Loggers,name=org.springframework.security
2017-03-03 21:17:56,060 localhost-startStop-2 DEBUG Registering MBean
org.apache.logging.log4j2:type=37b00782,component=Loggers,name=com.acme.backend
2017-03-03 21:17:56,061 localhost-startStop-2 DEBUG Registering MBean
org.apache.logging.log4j2:type=37b00782,component=Loggers,name=org.springframework.orm.jpa
2017-03-03 21:17:56,062 localhost-startStop-2 DEBUG Registering MBean
org.apache.logging.log4j2:type=37b00782,component=Loggers,name=org.hibernate.type
2017-03-03 21:17:56,063 localhost-startStop-2 DEBUG Registering MBean
org.apache.logging.log4j2:type=37b00782,component=Appenders,name=smtpAppender
2017-03-03 21:17:56,063 localhost-startStop-2 DEBUG Registering MBean
org.apache.logging.log4j2:type=37b00782,component=AsyncAppenders,name=asyncSmtpAppender
2017-03-03 21:17:56,064 localhost-startStop-2 DEBUG Registering MBean
org.apache.logging.log4j2:type=37b00782,component=Appenders,name=rollingFileAppender
2017-03-03 21:17:56,065 localhost-startStop-2 DEBUG Registering MBean
org.apache.logging.log4j2:type=37b00782,component=Appenders,name=consoleAppender
2017-03-03 21:17:56,066 localhost-startStop-2 TRACE Using DummyNanoClock for
nanosecond timestamps.
2017-03-03 21:17:56,066 localhost-startStop-2 DEBUG Reconfiguration complete
for context[name=37b00782] at URI
E:\Coding\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\pg-web-impl\WEB-INF\classes\log4j2.xml
(org.apache.logging.log4j.core.LoggerContext@28b6cf75) with optional
ClassLoader: null
2017-03-03 21:17:56,066 localhost-startStop-2 DEBUG Shutdown hook enabled.
Registering a new one.
2017-03-03 21:17:56,067 localhost-startStop-2 DEBUG
LoggerContext[name=37b00782,
[jira] [Comment Edited] (LOG4J2-1259) Log4j threads are leaking on Tomcat shutdown
[
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15894974#comment-15894974
]
Veit Guna edited comment on LOG4J2-1259 at 3/3/17 8:24 PM:
---
I just ran into the same problem using 2.8.1.
Apache Tomcat/8.0.20, jdk 1.8.0_66-b18, Windows 7.
I've added the log4j-web.jar, switched to servlet spec 3.0 in my web.xml and
I'm using Spring in my web application.
I've added an AsyncAppender in front of my SmtpAppender. Starting the webapp
and directly stopping it leads to:
{code}
Mär 03, 2017 9:17:56 PM org.apache.catalina.loader.WebappClassLoaderBase
clearReferencesThreads
WARNUNG: The web application [acme-backend] appears to have started a thread
named [AsyncAppender-asyncSmtpAppender] but has failed to stop it. This is very
likely to create a memory leak. Stack trace of thread:
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:403)
org.apache.logging.log4j.core.appender.AsyncAppender$AsyncThread.run(AsyncAppender.java:403)
{code}
Here's the output of status=trace
{code}
2017-03-03 21:09:58,741 localhost-startStop-1 DEBUG Starting
LoggerContext[name=Acme Backend] from configuration at null
2017-03-03 21:09:58,745 localhost-startStop-1 DEBUG Starting
LoggerContext[name=Acme Backend,
org.apache.logging.log4j.core.LoggerContext@554ad7a7] with configuration
XmlConfiguration[location=E:\Coding\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\acme-web-impl\WEB-INF\classes\log4j2.xml]...
2017-03-03 21:09:58,746 localhost-startStop-1 DEBUG Shutdown hook enabled.
Registering a new one.
2017-03-03 21:09:58,748 localhost-startStop-1 DEBUG Initializing configuration
XmlConfiguration[location=E:\Coding\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\acme-web-impl\WEB-INF\classes\log4j2.xml]
2017-03-03 21:09:58,755 localhost-startStop-1 DEBUG Installed script engines
2017-03-03 21:09:59,396 localhost-startStop-1 DEBUG Oracle Nashorn Version:
1.8.0_66, Language: ECMAScript, Threading: Not Thread Safe, Compile: true,
Names: {nashorn, Nashorn, js, JS, JavaScript, javascript, ECMAScript,
ecmascript}
2017-03-03 21:09:59,407 localhost-startStop-1 DEBUG Took 0,009540 seconds to
load 4 plugins from package com.acme.backend.service.rest.logging.log4j2
2017-03-03 21:09:59,407 localhost-startStop-1 DEBUG PluginManager 'Core' found
117 plugins
2017-03-03 21:09:59,407 localhost-startStop-1 DEBUG PluginManager 'Level' found
0 plugins
2017-03-03 21:09:59,425 localhost-startStop-1 DEBUG Building
Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
2017-03-03 21:09:59,443 localhost-startStop-1 TRACE TypeConverterRegistry
initializing.
2017-03-03 21:09:59,444 localhost-startStop-1 DEBUG PluginManager
'TypeConverter' found 26 plugins
2017-03-03 21:09:59,458 localhost-startStop-1 DEBUG
createProperty(name="logsPath", value="logs")
2017-03-03 21:09:59,458 localhost-startStop-1 DEBUG Building
Plugin[name=properties,
class=org.apache.logging.log4j.core.config.PropertiesPlugin].
2017-03-03 21:09:59,466 localhost-startStop-1 DEBUG
configureSubstitutor(={logsPath=logs},
Configuration(E:\Coding\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\acme-web-impl\WEB-INF\classes\log4j2.xml))
2017-03-03 21:09:59,467 localhost-startStop-1 DEBUG PluginManager 'Lookup'
found 14 plugins
2017-03-03 21:09:59,467 localhost-startStop-1 DEBUG Building
Plugin[name=layout, class=org.apache.logging.log4j.core.layout.PatternLayout].
2017-03-03 21:09:59,477 localhost-startStop-1 DEBUG
PatternLayout$Builder(pattern="%d %-5p [%mdc{RQID}] [%c{1}] - %m%n",
PatternSelector=null,
Configuration(E:\Coding\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\acme-web-impl\WEB-INF\classes\log4j2.xml),
Replace=null, charset="null", alwaysWriteExceptions="null",
disableAnsi="null", noConsoleNoAnsi="null", header="null", footer="null")
2017-03-03 21:09:59,478 localhost-startStop-1 DEBUG PluginManager 'Converter'
found 41 plugins
2017-03-03 21:09:59,507 localhost-startStop-1 DEBUG Building
Plugin[name=SizeBasedTriggeringPolicy,
class=org.apache.logging.log4j.core.appender.rolling.SizeBasedTriggeringPolicy].
2017-03-03 21:09:59,510 localhost-startStop-1 DEBUG createPolicy(size="10 MB")
2017-03-03 21:09:59,512 localhost-startStop-1 DEBUG Building
Plugin[name=Policies,
class=org.apache.logging.log4j.core.appender.rolling.CompositeTriggeringPolicy].
2017-03-03 21:09:59,513 localhost-startStop-1 DEBUG
createPolicy(={SizeBasedTriggeringPolicy(size=10485760)})
2017-03-03 21:09:59,513 localhost-startStop-1 DEBUG Building
Plugin[name=DefaultRolloverStrategy,
[jira] [Comment Edited] (LOG4J2-1259) Log4j threads are leaking on Tomcat shutdown
[
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510972#comment-15510972
]
Gary Gregory edited comment on LOG4J2-1259 at 9/21/16 7:50 PM:
---
In your Log4j configuration file, please set status to TRACE and lets see what
comes out on the console.
For example:
{code:xml}
...
{code}
Gary
was (Author: garydgregory):
In your Log4j configuration file, please set status to TRACE and lets see what
comes out on the console.
For example:
{code:xml}
...
{code}
Gary
> Log4j threads are leaking on Tomcat shutdown
>
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web
> also included in the web application deployed in Tomcat 8. The context
> listener is correctly starting up and shutting down, catalina.properties does
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown
[
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15492558#comment-15492558
]
Steffen Offermann edited comment on LOG4J2-1259 at 9/15/16 6:48 AM:
@[~garydgregory]:
In [comment
15473144|https://issues.apache.org/jira/browse/LOG4J2-1259?focusedCommentId=15473144=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15473144]
I confirmed that the threads now are shut down correctly, and that the tests
no longer break. That still holds. :)
What remains to do is described in issue LOG4J2-1573.
was (Author: steffeno):
@[~garydgregory]:
In [comment
15473144|https://issues.apache.org/jira/browse/LOG4J2-1259?focusedCommentId=15473144=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15473144]
I confirmed that the threads now are shut down correctly, and that the test no
longer break. That still holds. :)
What remains to do is described in issue LOG4J2-1573.
> Log4j threads are leaking on tomcat shutdown
>
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web
> also included in the web application deployed in Tomcat 8. The context
> listener is correctly starting up and shutting down, catalina.properties does
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown
[
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15492558#comment-15492558
]
Steffen Offermann edited comment on LOG4J2-1259 at 9/15/16 6:48 AM:
@[~garydgregory]:
In [comment
15473144|https://issues.apache.org/jira/browse/LOG4J2-1259?focusedCommentId=15473144=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15473144]
I confirmed that the threads now are shut down correctly, and that the test no
longer break. That still holds. :)
What remains to do is described in issue LOG4J2-1573.
was (Author: steffeno):
@[~garydgregory]:
In [comment
15473144|https://issues.apache.org/jira/browse/LOG4J2-1259?focusedCommentId=15473144=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15473144]
I confirmed that the threads now are shutdown correctly, and that the test no
longer break. That still holds. :)
What remains to do is described in issue LOG4J2-1573.
> Log4j threads are leaking on tomcat shutdown
>
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web
> also included in the web application deployed in Tomcat 8. The context
> listener is correctly starting up and shutting down, catalina.properties does
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown
[
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15492471#comment-15492471
]
Gary Gregory edited comment on LOG4J2-1259 at 9/15/16 5:53 AM:
---
[~SteffenO]: Can you reproduce?
was (Author: garydgregory):
@Steffen Offermann: Can you reproduce?
> Log4j threads are leaking on tomcat shutdown
>
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web
> also included in the web application deployed in Tomcat 8. The context
> listener is correctly starting up and shutting down, catalina.properties does
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown
[
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15476303#comment-15476303
]
Steffen Offermann edited comment on LOG4J2-1259 at 9/9/16 8:48 AM:
---
The field "layout" seems to be required for
{code:xml}
{code}
now, and that causes the error. Unfortunately the error log is useless as it
does not name the cause. I could only find this using the debugger.
According to the current documentation this is a bug:
||Parameter Name||Type||Description||
| layout | Layout | The Layout to use to format the LogEvent. If no layout is
supplied the default pattern layout of "%m%n" will be used.
With this configuration it works:
{code:xml}
{code}
I'll report this as a new issue.
was (Author: steffeno):
The field "layout" seems to be required for
{code:xml}
{code}
now, and that causes the error. Unfortunately the error log is useless as it
does not name the cause. I could only find this using the debugger.
According to the current documentation this is a bug:
||Parameter Name||Type||Description||
| layout | Layout | The Layout to use to format the LogEvent. If no layout is
supplied the default pattern layout of "%m%n" will be used.
With this configuration it works:
{code:xml}
{xml}
I'll report this as a new issue.
> Log4j threads are leaking on tomcat shutdown
>
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web
> also included in the web application deployed in Tomcat 8. The context
> listener is correctly starting up and shutting down, catalina.properties does
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown
[
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15476303#comment-15476303
]
Steffen Offermann edited comment on LOG4J2-1259 at 9/9/16 8:47 AM:
---
The field "layout" seems to be required for
{code:xml}
{code}
now, and that causes the error. Unfortunately the error log is useless as it
does not name the cause. I could only find this using the debugger.
According to the current documentation this is a bug:
||Parameter Name||Type||Description||
| layout | Layout | The Layout to use to format the LogEvent. If no layout is
supplied the default pattern layout of "%m%n" will be used.
With this configuration it works:
{code:xml}
{xml}
I'll report this as a new issue.
was (Author: steffeno):
The field "layout" seems to be required for
{code:xml}
{code}
now, and that causes the error. Unfortunately the error log is useless as it
does not name the cause. I could only find this using the debugger.
According to the current documentation this is a bug:
||Parameter Name||Type||Description||
| layout | Layout | The Layout to use to format the LogEvent. If no layout is
supplied the default pattern layout of "%m%n" will be used.
> Log4j threads are leaking on tomcat shutdown
>
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web
> also included in the web application deployed in Tomcat 8. The context
> listener is correctly starting up and shutting down, catalina.properties does
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown
[
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15476303#comment-15476303
]
Steffen Offermann edited comment on LOG4J2-1259 at 9/9/16 8:19 AM:
---
The field "layout" seems to be required for
{code:xml}
{code}
now, and that causes the error. Unfortunately the error log is useless as it
does not name the cause. I could only find this using the debugger.
According to the current documentation this is a bug:
||Parameter Name||Type||Description||
| layout | Layout | The Layout to use to format the LogEvent. If no layout is
supplied the default pattern layout of "%m%n" will be used.
was (Author: steffeno):
The field "layout" seems to be required for
{code:xml}
{code}
now, and that causes the error. Unfortunately the error log is useless as it
does not name the cause. I could only find this using the debugger.
> Log4j threads are leaking on tomcat shutdown
>
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web
> also included in the web application deployed in Tomcat 8. The context
> listener is correctly starting up and shutting down, catalina.properties does
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown
[
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15475189#comment-15475189
]
Gary Gregory edited comment on LOG4J2-1259 at 9/9/16 2:28 AM:
--
I've restored binary compatibility for TriggeringPolicy in Git master. I added
a TODO comment for 3.0 to extend LifeCycle.
was (Author: garydgregory):
I've restore binary compatibility for TriggeringPolicy in Git master. I added a
TODO comment for 3.0 to extend LifeCycle.
> Log4j threads are leaking on tomcat shutdown
>
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web
> also included in the web application deployed in Tomcat 8. The context
> listener is correctly starting up and shutting down, catalina.properties does
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown
[
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15475189#comment-15475189
]
Gary Gregory edited comment on LOG4J2-1259 at 9/8/16 10:19 PM:
---
I've restore binary compatibility for TriggeringPolicy in Git master. I added a
TODO comment for 3.0 to extend LifeCycle.
was (Author: garydgregory):
I've restore binary compatibility for TriggerPolicy in Git master. I added a
TODO comment for 3.0 to extend LifeCycle.
> Log4j threads are leaking on tomcat shutdown
>
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web
> also included in the web application deployed in Tomcat 8. The context
> listener is correctly starting up and shutting down, catalina.properties does
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown
[
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15473003#comment-15473003
]
Steffen Offermann edited comment on LOG4J2-1259 at 9/8/16 6:51 AM:
---
Thanks again, Gary!
{{RollingFileManager.releaseSub()}} is indeed called, but it holds a
{{CompositeTriggeringPolicy}}, which does not stop the nested policies because
it does not override the {{stop()}} method inherited from {{AbstractLifeCycle}}:
{code}
@Override
public boolean stop(final long timeout, final TimeUnit timeUnit) {
this.state = LifeCycle.State.STOPPED;
return true;
}
{code}
And the change also still breaks existing code, because the
{{TriggeringPolicy}} interface was changed. All artifacts using Log4j2 would
have to be recompiled, including the transitive dependencies.
was (Author: steffeno):
Thanks again, Gary!
{{RollingFileManager.releaseSub()}} is indeed called, but it holds a
{{CompositeTriggeringPolicy}}, which does not stop the nested policies because
it does not override the {{stop()}} methode inherited from
{{AbstractLifeCycle}}:
{code}
@Override
public boolean stop(final long timeout, final TimeUnit timeUnit) {
this.state = LifeCycle.State.STOPPED;
return true;
}
{code}
And the change also still breaks existing code, because the
{{TriggeringPolicy}} interface was changed. All artifacts using Log4j2 would
have to be recompiled, including the transitive dependencies.
> Log4j threads are leaking on tomcat shutdown
>
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web
> also included in the web application deployed in Tomcat 8. The context
> listener is correctly starting up and shutting down, catalina.properties does
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown
[
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471284#comment-15471284
]
Gary Gregory edited comment on LOG4J2-1259 at 9/7/16 5:40 PM:
--
Hi [~SteffenO],
The method {{RollingFileManager.releaseSub(long, TimeUnit)}} and all
{{*Manager.releaseSub(long, TimeUnit)}} methods are called from
{{AbstractManager.stop(long, TimeUnit)}}. A manager is stopped by it's appender
when that appender stops. It's up to each appender implementation to manage the
life-cycle of it's resource manager. In the case of
{{RollingFileAppender.stop(long, TimeUnit)}}, the manager is stored in the
super class {{AbstractOutputStreamAppender}} and stopped by a call to
{{super.stop(...)}}. An appender is stopped when the logger context is stopped.
So if you are not seeing the logger context stop, then that's the problem. Do
you see the logger context and appender being stopped?
When I step in the debugger for the test
{{org.apache.logging.log4j.core.appender.rolling.RollingAppenderCronTest}}, I
can see the future being canceled in
{{org.apache.logging.log4j.core.appender.rolling.CronTriggeringPolicy.stop(long,
TimeUnit)}}.
You must have a different code path. Can you check at which point the stop()
method calls do not go all the way through? Please try with the latest from Git
master.
Thank you,
Gary
was (Author: garydgregory):
Hi,
The method {{RollingFileManager.releaseSub(long, TimeUnit)}} and all
{{*Manager.releaseSub(long, TimeUnit)}} methods are called from
{{AbstractManager.stop(long, TimeUnit)}}. A manager is stopped by it's appender
when that appender stops. It's up to each appender implementation to manage the
life-cycle of it's resource manager. In the case of
{{RollingFileAppender.stop(long, TimeUnit)}}, the manager is stored in the
super class {{AbstractOutputStreamAppender}} and stopped by a call to
{{super.stop(...)}}. An appender is stopped when the logger context is stopped.
So if you are not seeing the logger context stop, then that's the problem. Do
you see the logger context and appender being stopped?
When I step in the debugger for the test
{{org.apache.logging.log4j.core.appender.rolling.RollingAppenderCronTest}}, I
can see the future being canceled in
{{org.apache.logging.log4j.core.appender.rolling.CronTriggeringPolicy.stop(long,
TimeUnit)}}.
You must have a different code path. Can you check at which point the stop()
method calls do not go all the way through?
> Log4j threads are leaking on tomcat shutdown
>
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web
> also included in the web application deployed in Tomcat 8. The context
> listener is correctly starting up and shutting down, catalina.properties does
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>
[jira] [Comment Edited] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown
[
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15470911#comment-15470911
]
Gary Gregory edited comment on LOG4J2-1259 at 9/7/16 3:26 PM:
--
I added an abstract class {{AbstractTriggeringPolicy}} that extends
{{AbstractLifeCycle}} and implements {{TriggeringPolicy}}. All of our Core
module triggering policies now extend {{AbstractTriggeringPolicy}}. Can you
have your TPs extend Core's ATP?
was (Author: garydgregory):
I added an abstract class {{AbstractTriggeringPolicy}} that extends
{{AbstractLifeCycle}} and implements {{TriggeringPolicy}}. All of our Core
module triggering policies now extend {{AbstractTriggeringPolicy}}.
> Log4j threads are leaking on tomcat shutdown
>
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web
> also included in the web application deployed in Tomcat 8. The context
> listener is correctly starting up and shutting down, catalina.properties does
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown
[
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15469033#comment-15469033
]
Gary Gregory edited comment on LOG4J2-1259 at 9/7/16 12:12 AM:
---
I have a tentative fix that lets {{TriggeringPolicy}} implement {{LiceCycle}}
which has a {{stop(long, TimeUnit)}} method. This {{TriggeringPolicy.stop(long,
TimeUnit)}} method can then be called from {{RollingFileManager.releaseSub(long
timeout, TimeUnit timeUnit)}}. A full build passes all tests. I'll commit it
and then you can test it.
was (Author: garydgregory):
I have a tentative fix that lets {{TriggeringPolicy}} implement {{LiceCycle}}
which has a {{stop(long, TimeUnit)}} method. This {{TriggeringPolicy.stop(long,
TimeUnit)}} method can then be called from {{RollingFileManager.releaseSub(long
timeout, TimeUnit timeUnit)}}. A full build passes all tests. I'll commit it
and then you can test it.
> Log4j threads are leaking on tomcat shutdown
>
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web
> also included in the web application deployed in Tomcat 8. The context
> listener is correctly starting up and shutting down, catalina.properties does
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown
[
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15467397#comment-15467397
]
Steffen Offermann edited comment on LOG4J2-1259 at 9/6/16 1:18 PM:
---
The problem is that the future holding the cron job (created via
{{ConfigurationScheduler.scheduleWithCron()}}) is never actively cancelled.
The {{CronTriggeringPolicy}} is the only one holding a reference to that
future, and stopping the executor service within {{ConfigurationScheduler}}
does not affect that future.
A possible solution might be to support the registration of shutdown listeners
in {{ConfigurationScheduler}}, so the {{CronTriggeringPolicy}} could register
itself there and cancel its future once the {{ConfigurationScheduler}} is shut
down.
was (Author: steffeno):
The problem is that the future holding the cron job (created via
{{ConfigurationScheduler.scheduleWithCron()}}) is never actively cancelled.
The {{CronTriggeringPolicy}} is the only one holding a reference to that
future, and stopping the executor service within {{ConfigurationScheduler}}
does not affect that future.
A possible solution might be to support the registration of shutdown listeners
in {{ConfigurationScheduler}}, so the {{CronTriggeringPolicy}} could register
itself there and cancel its future once the {{ConfigurationScheduler}} is
shutdown.
> Log4j threads are leaking on tomcat shutdown
>
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web
> also included in the web application deployed in Tomcat 8. The context
> listener is correctly starting up and shutting down, catalina.properties does
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown
[
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15466769#comment-15466769
]
Steffen Offermann edited comment on LOG4J2-1259 at 9/6/16 8:11 AM:
---
This (and the fact that the thread disappears once the next scheduled event was
fired) seems to prove that the remaining thread is associated with the
{{CronTriggeringPolicy}}:
{noformat}
06-Sep-2016 09:58:00.226 WARNING
[ContainerBackgroundProcessor[StandardEngine[Catalina]]]
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web
application [border-proxy] appears to have started a thread named
[Log4j2-TF-3-Scheduled-1] but has failed to stop it. This is very likely to
create a memory leak. Stack trace of thread:
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)
06-Sep-2016 09:59:00.002 INFO [Log4j2-TF-3-Scheduled-1]
org.apache.catalina.loader.WebappClassLoaderBase.checkStateForResourceLoading
Illegal access: this web application instance has been stopped already. Could
not load [org.apache.logging.log4j.core.lookup.JndiLookup]. The following stack
trace is thrown for debugging purposes as well as to attempt to terminate the
thread which caused the illegal access.
java.lang.IllegalStateException: Illegal access: this web application instance
has been stopped already. Could not load
[org.apache.logging.log4j.core.lookup.JndiLookup]. The following stack trace is
thrown for debugging purposes as well as to attempt to terminate the thread
which caused the illegal access.
at
org.apache.catalina.loader.WebappClassLoaderBase.checkStateForResourceLoading(WebappClassLoaderBase.java:1325)
at
org.apache.catalina.loader.WebappClassLoaderBase.checkStateForClassLoading(WebappClassLoaderBase.java:1313)
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1178)
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1139)
at
org.apache.logging.log4j.util.LoaderUtil.loadClass(LoaderUtil.java:139)
at
org.apache.logging.log4j.util.LoaderUtil.newInstanceOf(LoaderUtil.java:180)
at
org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOf(LoaderUtil.java:201)
at
org.apache.logging.log4j.core.util.Loader.newCheckedInstanceOf(Loader.java:300)
at
org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:96)
at
org.apache.logging.log4j.core.config.AbstractConfiguration.(AbstractConfiguration.java:119)
at
org.apache.logging.log4j.core.config.DefaultConfiguration.(DefaultConfiguration.java:46)
at
org.apache.logging.log4j.core.LoggerContext.(LoggerContext.java:81)
at
org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.createContext(ClassLoaderContextSelector.java:171)
at
org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.locateContext(ClassLoaderContextSelector.java:145)
at
org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:74)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:227)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:174)
at
org.apache.logging.log4j.core.LoggerContext.getContext(LoggerContext.java:187)
at
org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:257)
at
org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:177)
at
org.apache.logging.log4j.core.appender.rolling.CronTriggeringPolicy.rollover(CronTriggeringPolicy.java:127)
at
org.apache.logging.log4j.core.appender.rolling.CronTriggeringPolicy.access$100(CronTriggeringPolicy.java:40)
at
org.apache.logging.log4j.core.appender.rolling.CronTriggeringPolicy$CronTrigger.run(CronTriggeringPolicy.java:144)
at
org.apache.logging.log4j.core.config.ConfigurationScheduler$CronRunnable.run(ConfigurationScheduler.java:178)
at
[jira] [Comment Edited] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown
[
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15466627#comment-15466627
]
Steffen Offermann edited comment on LOG4J2-1259 at 9/6/16 8:10 AM:
---
I was able to do a local build, and the result was:
- Before undeploying the web application:
{noformat}
Thread Name Thread StateBlocked Count Blocked TimeWaited Count
Waited Time Total CPU Usage(%) Deadlocked Lock Name Lock
Owner ID Lock Owner Name Thread Id Native Suspended Allocated
Bytes(bytes)
Log4j2-TF-4-AsyncLoggerConfig-2 TIMED_WAITING 102 893
-45,623,600 Not Enabled
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@5118f78a
37 0 0 -256,236
Log4j2-TF-3-Scheduled-1 TIMED_WAITING 0 1
-45,623,600 Not Enabled
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@31d99db5
36 0 0 -256,236
{noformat}
- After undeploying the web application:
{noformat}
Thread Name Thread StateBlocked Count Blocked TimeWaited Count
Waited Time Total CPU Usage(%) Deadlocked Lock Name Lock
Owner ID Lock Owner Name Thread Id Native Suspended Allocated
Bytes(bytes)
Log4j2-TF-3-Scheduled-1 TIMED_WAITING 0 2
-45,623,600 Not Enabled
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@31d99db5
36 0 0 -256,236
{noformat}
- After redeploying the web application:
{noformat}
Thread Name Thread StateBlocked Count Blocked TimeWaited Count
Waited Time Total CPU Usage(%) Deadlocked Lock Name Lock
Owner ID Lock Owner Name Thread Id Native Suspended Allocated
Bytes(bytes)
Log4j2-TF-4-AsyncLoggerConfig-2 TIMED_WAITING 96 676
-45,623,600 Not Enabled
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@7d134f0b
69 0 0 -256,236
Log4j2-TF-3-Scheduled-1 TIMED_WAITING 0 1
-45,623,600 Not Enabled
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@5536ad8b
68 0 0 -256,236
Log4j2-TF-3-Scheduled-1 TIMED_WAITING 0 2
-45,623,600 Not Enabled
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@31d99db5
36 0 0 -256,236
{noformat}
- After undeploying it again:
{noformat}
Thread Name Thread StateBlocked Count Blocked TimeWaited Count
Waited Time Total CPU Usage(%) Deadlocked Lock Name Lock
Owner ID Lock Owner Name Thread Id Native Suspended Allocated
Bytes(bytes)
Log4j2-TF-3-Scheduled-1 TIMED_WAITING 0 2
-45,623,600 Not Enabled
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@5536ad8b
68 0 0 -256,236
Log4j2-TF-3-Scheduled-1 TIMED_WAITING 0 2
-45,623,600 Not Enabled
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@31d99db5
36 0 0 -256,236
{noformat}
I.e. one thread remains active with every deployment/undeployment. I had
managed to get that far with v2.6.2, too, in the meantime.
was (Author: steffeno):
I was able to do a local build, and the result was:
- Before undeploying the web application:
{noformat}
Thread Name Thread StateBlocked Count Blocked TimeWaited Count
Waited Time Total CPU Usage(%) Deadlocked Lock Name Lock
Owner ID Lock Owner Name Thread Id Native Suspended Allocated
Bytes(bytes)
Log4j2-TF-4-AsyncLoggerConfig-2 TIMED_WAITING 102 893
-45,623,600 Not Enabled
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@5118f78a
37 0 0 -256,236
Log4j2-TF-3-Scheduled-1 TIMED_WAITING 0 1
-45,623,600 Not Enabled
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@31d99db5
36 0 0 -256,236
{noformat}
- After undeploying the web application:
{noformat}
Thread Name Thread StateBlocked Count Blocked TimeWaited Count
Waited Time Total CPU Usage(%) Deadlocked Lock Name Lock
Owner ID Lock Owner Name Thread Id Native Suspended Allocated
Bytes(bytes)
Log4j2-TF-3-Scheduled-1 TIMED_WAITING 0 2
-45,623,600 Not Enabled
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@31d99db5
