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