Clint Weisbrod created LOG4J2-2178:
--------------------------------------
Summary: 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
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)
