[jira] [Assigned] (KAFKA-10877) Instantiating loggers for every FetchContext causes low request handler idle pool ratio.

["Tom Bentley (Jira)" <ji...@apache.org>]

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

Tom Bentley reassigned KAFKA-10877:
-----------------------------------

    Assignee: Sean McCauliff

> Instantiating loggers for every FetchContext causes low request handler idle pool ratio.
> ----------------------------------------------------------------------------------------
>
>                 Key: KAFKA-10877
>                 URL: https://issues.apache.org/jira/browse/KAFKA-10877
>             Project: Kafka
>          Issue Type: Bug
>            Reporter: Sean McCauliff
>            Assignee: Sean McCauliff
>            Priority: Major
>
> JDK11 has removed some classes used by log4j2 to initialize logging contexts.  Now log4j2 uses StackWalker to discover where it has been instantiated.  StackWalker is apparently very expensive.
> Kafka has a Logging trait.  Classes which want to log application messages get access to the methods provided by the trait by mixing them in using "with Logging".  When this is done on scala object (a singleton) this is fine as the logging context in the Logging trait is only initialized at most once.   When this is done on class (e.g. class X extends Logging) the logging context is potentially created for each instance.  The logging context is needed to determine if a log message will be emitted.  So if the method debug("log me") is called the logging context is still initialized to determine if debug logging is enabled.  Initializing the logging context calls StackWalker.  This can't be avoided even if the log message would never be written to the log.
> IncrementalFetchContext is one such class that is inheriting from Logging and incurring a very high cpu cost.  It also does this inside of locks.
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)