[
https://issues.apache.org/jira/browse/LOG4J2-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17290637#comment-17290637
]
Ralph Goers edited comment on LOG4J2-3026 at 2/25/21, 3:52 AM:
---------------------------------------------------------------
You are going to have to do more than commit something without explaining what
you think you are fixing.
WatchManager is created with the ConfigurationScheduler as a parameter.
AbstractConfiguration's stop method first stops the WatchManager and then stops
the ConfigurationScheduler. Always.
Then you modified the test to remove having the test shutdown the
ConfigurationScheduler to "prove" that your new code works. But since prior to
this commit ConfigurationScheduler and WatchManager are always shut down
together the change to this test makes no sense.
Please explain how having the WatchManager stop the ConfigurationScheduler
fixes anything or is even a good idea since it wasn't the one to create it.
was (Author: [email protected]):
You are going to have to do more than commit something without explaining what
you think you are fixing.
WatchManager is created with the ConfigurationScheduler as a parameter.
AbstractConfiguration's stop method first stops the WatchManager and then stops
the ConfigurationScheduler. Always.
Then you modified the test to remove having the test shutdown the
ConfigurationScheduler to "prove" that your new code works. But since
ConfigurationScheduler shuts down the WatchManager this test makes no sense.
Please explain how having the WatchManager stop the ConfigurationScheduler
fixes anything or is even a good idea since it wasn't the one to create it.
> WatchManager does not stop its ConfigurationScheduler thereby leaking a thread
> ------------------------------------------------------------------------------
>
> Key: LOG4J2-3026
> URL: https://issues.apache.org/jira/browse/LOG4J2-3026
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.14.0
> Reporter: Gary D. Gregory
> Assignee: Gary D. Gregory
> Priority: Major
> Fix For: 3.0.0, 2.14.1
>
>
> The {{WatchManager}} does not stop its {{ConfigurationScheduler}} thereby
> leaking a thread as reported by Tomcat 9:
> {noformat}
> 24-Feb-2021 14:13:49.747 WARNING [http-nio-8080-exec-9]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [discoveryrecorder] appears to have started a thread named
> [Log4j2-TF-8-Scheduled-2] 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:1074)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> java.lang.Thread.run(Thread.java:748)
> {noformat}
> I am experiencing this in 2.14.0 but it looks to have been a bug since day 1.
> Windows 10, Java 8.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
