[
https://issues.apache.org/jira/browse/LOG4J2-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15188988#comment-15188988
]
Remko Popma commented on LOG4J2-1116:
-------------------------------------
Looking at Log4jThreadLocal: now I'm happy again. :-) Nice work, Ralph!
Some details:
* It may be a good idea to store the actual values in a
{{java.util.concurrent.atomic.AtomicReference}} in the internal ThreadLocal,
rather than a non-JDK class like {{Container}}.
* I would prefer to use the Thread object itself as the key into the
ConcurrentMap, rather than the thread ID. It seems slightly simpler, faster and
removes the need for auto-boxing.
* I would like to add a convenience method {{public static void clearAll()}}
which would call {{clear}} on all instances of Log4jThreadLocal. The
Log4jThreadLocal constructor would add each instance to a static list for this
purpose. (Access to this static list could be synchronized to make it thread
safe.)
This class would allow us to remove the dual implementations I mentioned above.
I like it!
> 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
> Attachments: Log4jThreadLocal.java
>
>
> 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]
