[jira] [Commented] (LOG4J2-2178) Log4j2 ThreadNameCachingStrategy CACHED vs UNCACHED alternative

["Gary Gregory (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LOG4J2-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16312054#comment-16312054 ] 

Gary Gregory commented on LOG4J2-2178:
--------------------------------------

Thank you for you request.

Maybe we need to abstract that in a util class/method like setThreadName(Thread thread, String name) which calls setName() and then does whatever housekeeping based on the thread caching strategy. Maybe we'd need a new strategy as well CACHE_ALLOW_INVALIDATE or some such. Discuss!

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