[
https://issues.apache.org/jira/browse/LOG4J2-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129465#comment-14129465
]
Gary Gregory commented on LOG4J2-819:
-------------------------------------
I disagree, from my reply on the ML:
Hi Remko & Matt,
Thank you for chiming in.
As of now, the threads still exist and are not cleanly stoppable. The only way
to cleanly and _simply_ stop a thread is with a flag as the patch does. From a
design stand point it does not smell right to start threads and not offer a
clean way to stop them. So that's one point I see in favor of _at least_ having
the new cleaner clocks in master. Whether or not we stop them automatically is
another issue.
I see your point about web apps but that only means (to me) that out web
integration needs to override the clock factory with one that does not use a
thread. If the user configures a thread based clock anyway, then what? He or
she is hosed? That does not sound right.
So from a process POV, I would like to:
(1) Agree on how to stop a thread-based clock (my patch minus the call from the
web code).
(2) Discuss on who should do the stopping, if any one. At worse, the use can
call the stop() method. At least we would have something in 2.1...
Thoughts?
> 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.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]
