[
https://issues.apache.org/jira/browse/KAFKA-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14592390#comment-14592390
]
E. Sammer commented on KAFKA-2285:
----------------------------------
The if guard isn't the issue. Any invocation of a logger captures its call
site, so it can't be wrapped in any kind of method. Libraries like slf4j handle
the expensive string construction problem fine and since none of the debug
level messages are in the critical data path (i.e. for each message), I can't
imagine this is the thing that dramatically impacts performance.
> Logging trait obfuscates call site information
> ----------------------------------------------
>
> Key: KAFKA-2285
> URL: https://issues.apache.org/jira/browse/KAFKA-2285
> Project: Kafka
> Issue Type: Improvement
> Components: core
> Affects Versions: 0.8.2.0
> Reporter: E. Sammer
>
> Using a logging trait, as many components in the codebase do, destroys call
> site information in logging message making debugging certain kinds of
> failures annoying in production systems. Most messages end up look like:
> {code}
> 2015-06-18 07:41:11,550 (kafka-request-handler-0) [WARN -
> kafka.utils.Logging$class.warn(Logging.scala:83)] Partition [events,1] on
> broker 1: No checkpointed highwatermark is found for partition [events,1]
> {code}
> I think the mental overhead of issuing the standard incantation of {{private
> static final Logger logger = LoggerFactory.get(Foo.class)}} (or the even
> shorter Scala equivalent) for each class is outweighed by the operational
> overhead of mapping strings back to their original call sites. This is an
> easy win improve the traceability of complex failures in production
> deployments.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
