[
https://issues.apache.org/jira/browse/LOG4J2-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193093#comment-15193093
]
Ralph Goers commented on LOG4J2-1116:
-------------------------------------
Yes, it should be possible to not create the ReusableMessageFactory if there is
no registry.
I am not sure what you mean by "complexity". I specifically wanted to have the
implementation in log4j-core and not in the API, partly because doing it this
way has little chance of affecting comparability. The only real complexity
making them non-static introduced is it affects serialization.
I specifically don't want to make any assumptions about how to locate the
LoggerContext. The way I implemented this the LoggerContext should always be
available, so it can't possibly be wrong.
Although I don't really view whether the ThreadLocals can be static or not very
significant to the solution, if you have the log4j jars in tomcat/lib with
static ThreadLocals you will only have a single ThreadLocal for all web apps.
Calling clear will clear them all, which will affect all web apps, even though
each web app has its own MessageFactory. If the are non-static that won't
happen. Only the ThreadLocal associated with the LoggerContext will be cleared.
> 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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
