hadoop-mapreduce-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jagadesh Kiran N (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MAPREDUCE-6468) Consistent log severity level guards and statements in MapReduce project
Date Tue, 08 Sep 2015 15:07:46 GMT

    [ https://issues.apache.org/jira/browse/MAPREDUCE-6468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14734959#comment-14734959

Jagadesh Kiran N commented on MAPREDUCE-6468:

thanks [~ozawa] for your review, I have updated the patch, Please review  , no change required
for ProtobufRpcEngine.java file .

> Consistent log severity level guards and statements in MapReduce project
> ------------------------------------------------------------------------
>                 Key: MAPREDUCE-6468
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-6468
>             Project: Hadoop Map/Reduce
>          Issue Type: Improvement
>            Reporter: Jackie Chang
>            Assignee: Jagadesh Kiran N
>            Priority: Minor
>              Labels: BB2015-05-TBR
>         Attachments: HADOOP-9995-00.patch, HADOOP-9995.patch, MAPREDUCE-6468-01.patch,
> Developers use logs to do in-house debugging. These log statements are later demoted
to less severe levels and usually are guarded by their matching severity levels. However,
we do see inconsistencies in trunk. A log statement like 
> {code}
>        if (LOG.isDebugEnabled()) {
>         LOG.info("Assigned container (" + allocated + ") "
> {code}
> doesn't make much sense because the log message is actually only printed out in DEBUG-level.
We do see previous issues tried to correct this inconsistency. I am proposing a comprehensive
correction over trunk.
> Doug Cutting pointed it out in HADOOP-312: https://issues.apache.org/jira/browse/HADOOP-312?focusedCommentId=12429498&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12429498
> HDFS-1611 also corrected this inconsistency.
> This could have been avoided by switching from log4j to slf4j's {} format like CASSANDRA-625
(2010/3) and ZOOKEEPER-850 (2012/1), which gives cleaner code and slightly higher performance.

This message was sent by Atlassian JIRA

View raw message