[ 
https://issues.apache.org/jira/browse/KAFKA-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14592415#comment-14592415
 ] 

Grant Henke commented on KAFKA-2285:
------------------------------------

I agree. My suggestion was a way to move the call site out of the trait and 
into the correct class, while still utilizing the trait to "auto generate" the 
if guard (at the correct call site). The goal being that the code did not need 
to be littered with if guards, there was no performance degradation, and 
minimal code change.

Slf4j and other logging libraries all have ways to handle the expensive 
parameter construction problem 
(http://www.slf4j.org/faq.html#logging_performance). But that is either guard 
statements or parameterized messages. Unfortunately Kafka's logging statements 
are not parameterized and many of them use String.format and + concatenation.

Changing all the log statements to use parameterized messages is also an option.

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

Reply via email to