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)
