[ 
https://issues.apache.org/jira/browse/LOG4J2-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1116:
--------------------------------
    Assignee: Ralph Goers  (was: Remko Popma)

Okay, no problem. I also started to do some work on this but happy to leave it 
to you. 

Personally I would be fine with putting this in log4j-api because it simplifies 
things quite a bit. One key assumption I'm making is that looking up the 
context with {{LogManager.getContext(false)}} would always return the correct 
context even with the log4j jars in the web container shared library folder.

The way I was approaching this is that log4j-api's util package would have 
Log4jThreadLocal, Log4jThreadLocalFactory and the Log4jThreadLocalRegistry 
interface. log4j-core's LoggerContext would implement the registry interface.

The factory and registry I was thinking of look like this:
{code}
package org.apache.logging.log4j.util;

public class Log4jThreadLocalFactory {
    public static <T> Log4jThreadLocal<T> create(final Class<T> cls) {
        final LoggerContext context = LogManager.getContext(false);
        final Log4jThreadLocal<T> result = new Log4jThreadLocal<>();
        if (context instanceof Log4jThreadLocalRegistry) {
            ((Log4jThreadLocalRegistry) context).register(result);
        }
        return result;
    }
}

public interface Log4jThreadLocalRegistry {
    void register(final Log4jThreadLocal<?> threadLocal);
    void clear();
}
{code}

Then for example ReusableMessageFactory would look like this
{code}
...
private static ThreadLocal<ReusableSimpleMessage> threadLocalSimpleMessage = 
Log4jThreadLocalFactory.create(ReusableSimpleMessage.class);
...
{code}

I have not thought the static bit through yet. Would that still be a problem? 
If the LoggerContext is stopped, it traverses through the thread locals that 
are registered in _that_ context only, so it should not affect thread locals 
that are registered in other contexts, or am I missing something?

> 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
>
>
> 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]

Reply via email to