Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Date: Sat, 28 Sep 2013 00:39:03 +0000 (UTC)
From: "Jackie Chang (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.12670626.1380166607066.33995.1380328743057@arcas>
In-Reply-To: <JIRA.12670626.1380166607066@arcas>
References: <JIRA.12670626.1380166607066@arcas>
Subject: [jira] [Updated] (HADOOP-9995) Consistent log severity level guards
 and statements
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HADOOP-9995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jackie Chang updated HADOOP-9995:
---------------------------------

    Description: 
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.

  was:
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 like CASSANDRA-625 (2010/3) and ZOOKEEPER-850 (2012/1).

    
> Consistent log severity level guards and statements 
> ----------------------------------------------------
>
>                 Key: HADOOP-9995
>                 URL: https://issues.apache.org/jira/browse/HADOOP-9995
>             Project: Hadoop Common
>          Issue Type: Improvement
>            Reporter: Jackie Chang
>            Priority: Minor
>         Attachments: HADOOP-9995.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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira