Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Date: Thu, 3 Oct 2013 07:03:02 +0000 (UTC)
From: "Hadoop QA (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.12670626.1380166607066.5441.1380783782025@arcas>
In-Reply-To: <JIRA.12670626.1380166607066@arcas>
References: <JIRA.12670626.1380166607066@arcas>
Subject: [jira] [Commented] (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:comment-tabpanel&focusedCommentId=13784870#comment-13784870 ] 

Hadoop QA commented on HADOOP-9995:
-----------------------------------

{color:red}-1 overall{color}.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12605179/HADOOP-9995.patch
  against trunk revision .

    {color:green}+1 @author{color}.  The patch does not contain any @author tags.

    {color:red}-1 tests included{color}.  The patch doesn't appear to include any new or modified tests.
                        Please justify why no new tests are needed for this patch.
                        Also please list what manual steps were performed to verify this patch.

    {color:green}+1 javac{color}.  The applied patch does not increase the total number of javac compiler warnings.

    {color:green}+1 javadoc{color}.  The javadoc tool did not generate any warning messages.

    {color:green}+1 eclipse:eclipse{color}.  The patch built with eclipse:eclipse.

    {color:green}+1 findbugs{color}.  The patch does not introduce any new Findbugs (version 1.3.9) warnings.

    {color:green}+1 release audit{color}.  The applied patch does not increase the total number of release audit warnings.

    {color:red}-1 core tests{color}.  The patch failed these unit tests in hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app hadoop-tools/hadoop-distcp hadoop-tools/hadoop-gridmix hadoop-yarn-project/hadoop-yarn/hadoop-yarn-client hadoop-yarn-project/hadoop-yarn/hadoop-yarn-common hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager:

                  org.apache.hadoop.tools.mapred.TestCopyMapper

    {color:green}+1 contrib tests{color}.  The patch passed contrib unit tests.

Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/3159//testReport/
Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/3159//console

This message is automatically generated.

> 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 was sent by Atlassian JIRA
(v6.1#6144)