[
https://issues.apache.org/jira/browse/LOG4J2-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15188395#comment-15188395
]
Ralph Goers commented on LOG4J2-1116:
-------------------------------------
The problem I see is that the ThreadLocalMap attached to each thread has no
synchronization. This is because the map is only manipulated when executing on
that Thread. to perform a clear operation we would either have to find a way to
safely manipulate the map from a different thread (I doubt that can be done) or
somehow cause remove to be executed on each thread that has an instance of the
thread local.
The only other way to do this is to implement something that doesn't use the
ThreadLocalMap - perhaps using a ConcurrentHashMap with the threadId as the
key. I suspect this would be quite a bit slower. You would need to create a
performance test to determine how much of a performance hit this would be.
> 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]
