[
https://issues.apache.org/jira/browse/LOG4J2-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14131604#comment-14131604
]
Remko Popma commented on LOG4J2-819:
------------------------------------
By the way, why do you need a boolean flag? Isn't it simpler to just call
{{updaterThread.interrupt();}} from the clock's stop() method, and change the
run() method to {{while (!interrupted()) \{...\}}}. The sleep time in this case
is only one millisecond, but in general interrupt is better than a stop flag
because it allows the thread to detect that it was stopped and return early
from its call to sleep(). The biggest advantage in this case is that you don't
need to build infrastructure to maintain the boolean anymore, so no need for
the StopFlagThread any more. (The Thread.interrupt() method is not deprecated
like the Thread.stop(), suspend() and resume() methods.)
That said, I still don't like having a public {{Clock.stop() method}}. This
unloads the gun for web apps (so they can no longer shoot themselves in the
foot even if they try), but also hands out the gun to everyone else so they can
shoot themselves (by stopping the clock prematurely)... :-(
> 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-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: [email protected]
For additional commands, e-mail: [email protected]
