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

["Sean McCauliff (Jira)" <ji...@apache.org>]

Sean McCauliff created KAFKA-10877:
--------------------------------------

             Summary: 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


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)