[
https://issues.apache.org/jira/browse/KAFKA-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14591990#comment-14591990
]
Grant Henke commented on KAFKA-2285:
------------------------------------
It looks like it's where the call to _logger.*_ is that really matters.
However, the Kafka Logging trait guards every call with
_if (logger.isLevelEnabled())_ so moving the calls out to the code would be
messy or potentially impact performance.
The scala-logging (https://github.com/typesafehub/scala-logging) library could
be nice solution. It uses a macro at compile time to turn calls like:
_logger.debug(s"Some $expensive message!")_ into _if (logger.isDebugEnabled)
logger.debug(s"Some $expensive message!")_
And preserves the call site since _logger._* is called in the class which mixes
in the trait.
If adding a dependency is an issue the library is small enough that we could
implement our own version on similar principles.
> 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)