[jira] [Updated] (MAPREDUCE-6468) Consistent log severity level guards and statements in MapReduce project

2015-09-09 Thread Jagadesh Kiran N (JIRA)

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

Jagadesh Kiran N updated MAPREDUCE-6468:

Attachment: MAPREDUCE-6468-03.patch

Attaching the patch.Addressed white spaces and check style.Findbugs need to 
check as no issue displayed. Test failures are not part of patch updation.

> 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, MAPREDUCE-6468-02.patch, MAPREDUCE-6468-03.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=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.3.4#6332)


[jira] [Updated] (MAPREDUCE-6468) Consistent log severity level guards and statements in MapReduce project

2015-09-09 Thread Jagadesh Kiran N (JIRA)

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

Jagadesh Kiran N updated MAPREDUCE-6468:

Attachment: MAPREDUCE-6468-04.patch

[~ozawa] thanks for your review, addressed all your comments in this patch 
,please review

> 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, MAPREDUCE-6468-02.patch, MAPREDUCE-6468-03.patch, 
> MAPREDUCE-6468-04.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=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.3.4#6332)


[jira] [Updated] (MAPREDUCE-6468) Consistent log severity level guards and statements in MapReduce project

2015-09-08 Thread Tsuyoshi Ozawa (JIRA)

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

Tsuyoshi Ozawa updated MAPREDUCE-6468:
--
Summary: Consistent log severity level guards and statements in MapReduce 
project  (was: Consistent log severity level guards and statements in 
RMContainerAllocator)

> 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=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.3.4#6332)


[jira] [Updated] (MAPREDUCE-6468) Consistent log severity level guards and statements in MapReduce project

2015-09-08 Thread Jagadesh Kiran N (JIRA)

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

Jagadesh Kiran N updated MAPREDUCE-6468:

Attachment: MAPREDUCE-6468-02.patch

> 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, MAPREDUCE-6468-02.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=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.3.4#6332)