[
https://issues.apache.org/jira/browse/LOG4J2-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15192745#comment-15192745
]
Ralph Goers edited comment on LOG4J2-1116 at 3/14/16 5:18 AM:
--------------------------------------------------------------
I have actually started work on this but am nowhere near done. I was actually
able to leave Log4jThreadLocal in core as everything in the API thinks it is
just using a ThreadLocal. There is a ThreadLocalRegistry that is added to the
API along with a ThreadLocalRegistryAware. The Registry implementation actually
creates the Log4jThreadLocal as the caller just requests the ThreadLocal it
wants by name.
So in the ReusableMessageFractory the constructor initializes the ThreadLocals
by calling registry.get(String name) with the name of each Message type as the
key.
Also, I had to change the ThreadLocals in ReusableMessageFactory from statics.
Again, that will cause a problem if the Log4j jars are in the tomcat/lib and a
web app is underplayed.
Where I am at now is passing the registry from the LoggerContext to
AbstractLogger. The Core Logger has a reference to the LoggerContext so it can
pass it to AbstractLogger. However, other Logger implementations may not have a
Registry so these components should probably fall back to creating new Messages
if a registry is not available.
was (Author: ralph.go...@dslextreme.com):
I have actually started work on this but am nowhere near done. I was actually
able to leave Log4jThreadLocal in core as everything in the API thinks it is
just using a ThreadLocal. There is a ThreadLocalRegistry that is added to the
API along with a ThreadLocalRegistryAware. The Registry implementation actually
creates the Log4jThreadLocal as the caller just requests the ThreadLocal it
wants by name.
So in the ReusableMessageFractory the constructor initializes the ThreadLocals
by calling registry.get(String name) with the name of each Message type as the
key.
Also, I had to change the ThreadLocals in ReusableMessageFactory from statics.
Again, that will cause a problem if the Log4j jars are in the tomcat/lib and a
web app is undeployed.
> 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: Remko Popma
> Priority: Critical
> Fix For: 2.6
>
> 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: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
