[
https://issues.apache.org/jira/browse/LOG4J2-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14131771#comment-14131771
]
Remko Popma commented on LOG4J2-819:
------------------------------------
[~garydgregory] My thinking is/was that the thread should not be started in the
first place. Then we don't need to stop them and there is no use case for a
stop() method.
However I am assuming that this thread is only started in a web app by mistake.
If I'm wrong about that, then we don't have much choice...
How about having a subinterface StoppableClock extending Clock with the stop()
method, and the call site would do an instanceof. Would that be overkill? That
would make it less easy to call ClockFactory.getClock().stop() by mistake. And
we can document that this interface and its stop() method are for Log4j
internal housekeeping purposes.
About the patch, I like that we have less API surface in the interrupt version.
Would you oppose removing AbstractClock as well? (SystemClock can just
implement the empty stop() method directly.) About the thread name, do you want
the fully qualified class name, e.g.
org.apache.logging.log4j.core.util.CoarseCachedClock, in the thread name, or
class.getSimpleName?
About the call site, I initially thought about calling stop() from
LoggerContext.stop(), but that would cause the clock to stop updating when
Log4j is reconfigured. It is probably a good idea to only call Clock
(StoppableClock?).stop() when the webapp is unloaded.
> PermGen OutOfMemoryError when reloading webapp on Tomcat 6
> ----------------------------------------------------------
>
> Key: LOG4J2-819
> URL: https://issues.apache.org/jira/browse/LOG4J2-819
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0.2
> Environment: Tomcat 6
> Reporter: Costa Theodosiou
> Priority: Critical
> Attachments: gg-log4j2-clocks-interrupts.patch,
> gg-log4j2-clocks-v2.patch
>
>
> When reloading an application 3 or 4 times in Tomcat 6, the application
> crashes with a "java.lang.OutOfMemoryError: PermGen space" exception.
> After some investigation using the "When all else fails" section of
> https://wiki.apache.org/tomcat/OutOfMemory in conjunction with Java VisualVM,
> I have narrowed down the problem to the Thread created within
> org.apache.logging.log4j.core.util.CoarseCachedClock.
> When a Thread is created, it contains a reference to the classloader that it
> was created with. In this case, the Thread's contextClassLoader field
> contains a reference to the WebappClassLoader. When Tomcat attempts to unload
> the webapp, the Thread still holds onto this reference which prevents
> WebappClassLoader from being freed.
> Perhaps the Log4jServletContextListener (Log4jWebInitializerImpl) can be made
> to stop the CoarseCachedClock thread.
> I believe this is not an obvious issue on Tomcat 7 due to
> https://wiki.apache.org/tomcat/MemoryLeakProtection.
--
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
