logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remko Popma (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-1116) Web app-friendly thread locals for gc-free logging (was: upgrade to log4j2 causes too frequent minor gc)
Date Mon, 14 Mar 2016 08:33:33 GMT

    [ https://issues.apache.org/jira/browse/LOG4J2-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15192911#comment-15192911

Remko Popma commented on LOG4J2-1116:

Thanks for pushing that branch.

I noticed that ReusableMessageFactory now needs to check if the ThreadLocal is null for each
call to {{newMessage}}. I think it is worth avoiding that check in the critical path. Is it
possible to not create a ReusableMessageFactory in the first place if there is no ThreadLocalRegistry
available to back it up?

Another thing I'm not clear about yet is whether ThreadLocal fields can be static or not.
It seems to me that a lot of the complexity would go away if they _can_ be static, so it is
worth considering this.

The key question is: can we make the assumption that looking up the context with LogManager.getContext(false)
would always returns the correct context even with the log4j jars in the web container shared
library folder? If that works, then even if the wrapper ThreadLocal is static, its contents
are actually registered in the correct context and will be cleared if that context is stopped
without affecting the thread locals of other contexts.

> Web app-friendly thread locals for gc-free logging (was: 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
>            Assignee: Ralph Goers
>            Priority: Critical
>             Fix For: 2.6
>         Attachments: Log4jThreadLocal.java, 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

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message