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