[
https://issues.apache.org/jira/browse/LOG4J2-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma reassigned LOG4J2-2178:
-----------------------------------
Assignee: Remko Popma
> Log4j2 ThreadNameCachingStrategy CACHED vs UNCACHED alternative
> ---------------------------------------------------------------
>
> Key: LOG4J2-2178
> URL: https://issues.apache.org/jira/browse/LOG4J2-2178
> Project: Log4j 2
> Issue Type: Improvement
> Components: API, Core
> Reporter: Clint Weisbrod
> Assignee: Remko Popma
> Priority: Minor
>
> It came to my attention a few weeks ago that by default, log4j2 caches the
> thread name of the calling thread to reduce overhead each time a new LogEvent
> is created. Refer to ReusableLogEventFactory.createEvent() in the source
> code. This is the correct approach most of the time but of course, there are
> situations where a developer will give a thread a new name after this thread
> has made at least one logging call.
> At present, the only way that log4j2 will detect changes to a thread's name
> (and subsequently write this new thread name to its logs) is to make use of
> ThreadNameCachingStrategy.UNCACHED. When initializing log4j2 (before any
> logging events are created), the system property called
> "AsyncLogger.ThreadNameStrategy" is queried. If its value is "UNCACHED", this
> forces log4j2 to ask for the current thread's name (and thread priority) for
> EVERY call to ReusableLogEventFactory.createEvent() (every log event).
> I've read over performance comparisons between CACHED and UNCACHED thread
> name logging modes. There is definitely a difference and IMHO, this is quite
> sad. Most people (including myself) choose log4j2 as their logging platform
> specifically because it is much faster than the built-in Java solution found
> in java.util.logging.
> Unfortunately, the way CACHED vs UNCACHED is implemented, there is no way to
> change the behavior once a thread has made a call to log an event. This is
> because the value of the system property "AsyncLogger.ThreadNameStrategy" is
> also cached at startup. In other words, if you know you will be changing the
> name of a thread and you need that new name to appear in your logs, you're
> stuck using the UNCACHED mode for the lifetime of your application. And
> perhaps this point is moot but this mode applies to all threads in your
> application.
> Given all this, rather than impact all threads over application lifetime, can
> I suggest to the jog4j2 developers, the addition of a new method in
> org.apache.logging.log4j.Logger called something like
> refreshCachedThreadName()? In practice, this new method would be called by
> the application immediately after a thread's name has been changed by a call
> to Thread.setName(). This places the responsibility on the application
> developer to deal with the renamed thread at a cost of not incurring the
> additional overhead to read the thread's name and priority per log event.
> I really hope this suggestion can be incorporated. It would make an already
> great logging platform even greater.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
