[
https://issues.apache.org/jira/browse/LOG4J2-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15186475#comment-15186475
]
Remko Popma commented on LOG4J2-1116:
-------------------------------------
If each web-app has its own copy of the log4j jars, the log4j classes are
loaded by the web-app classloader. Then, any ThreadLocal holding a log4j class
will have a reference to the web-app classloader. When the web-app is stopped
or reloaded, the threads in the pool will still have ThreadLocals that point to
the web-app that was destroyed, and because of this reference they cannot be
garbage collected, causing a memory leak.
(One solution is to configure the web container to refresh the thread pool when
a web app is unloaded or restarted, but not sure what impact that may have on
other web apps when their ThreadLocal information is thrown out.)
When the log4j jars are in the web container library they are loaded by a
classloader unrelated to any web app, so thread pools having a reference to
log4j classes should not prevent web app classes from being garbage collected
after the app is stopped.
> upgrade to log4j2 causes too frequent minor gc
> ----------------------------------------------
>
> Key: LOG4J2-1116
> URL: https://issues.apache.org/jira/browse/LOG4J2-1116
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.3
> Environment: jdk1.6
> slf4j 1.7.9
> log4j2.3
> Reporter: Mingjiang Shi
> Priority: Critical
>
> We used slf4j+log1.2 in our spring web application. Due to the log4j1.0
> performance issue, we upgrade it to log4j2. When it goes to production, it
> experienced very frequent minor gc (once per second) even though the eden
> area is not full. For example, the eden area just occupied 10%, the minor gc
> also happens. The issue disappears when rolling back to log4j1.2.
> Can anyone show some hints on diagnose this issue? Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
