[
https://issues.apache.org/jira/browse/LOG4J2-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15188069#comment-15188069
]
Remko Popma commented on LOG4J2-1116:
-------------------------------------
Just to be clear, we are talking about using reflection to provide a way to
clean up ThreadLocals on Log4j shutdown, right?
It is not my intention to re-implement the core behaviour of ThreadLocal (the
ThreadLocal map): that would never be as performant as the JDK ThreadLocal.
Rather than subclassing we can decorate ThreadLocal, and the decorator class
can capture the set of Threads on to which the ThreadLocals were registered. At
shutdown, we can then call the decorator to clean up all known ThreadLocals
from all known Threads. This cleanup action is on a best effort-basis since it
uses reflection and may fail.
> 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: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
