[
https://issues.apache.org/jira/browse/KAFKA-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17253152#comment-17253152
]
Sean McCauliff commented on KAFKA-10877:
----------------------------------------
Yes I'm getting a PR ready. My plan is to move the logging context into
companion objects. It's not clear if there are other places in the code (other
than that also need modification, however. Can you think of any [~ijuma]?
> 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
> 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)
