[jira] [Commented] (MAPREDUCE-6496) Incorrect javadoc in WritableUtils.java

2015-10-06 Thread Jagadesh Kiran N (JIRA) 

[ 
https://issues.apache.org/jira/browse/MAPREDUCE-6496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945081#comment-14945081
 ] 

Jagadesh Kiran N commented on MAPREDUCE-6496:
-

The Failures are not related to patch [~ajisakaa] Please review

> Incorrect javadoc in WritableUtils.java
> ---
>
> Key: MAPREDUCE-6496
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6496
> Project: Hadoop Map/Reduce
>  Issue Type: Bug
>Affects Versions: 2.7.1
>Reporter: Martin Petricek
>Assignee: Jagadesh Kiran N
>Priority: Minor
> Attachments: MAPREDUCE-6496-00.patch, MAPREDUCE-6496-01.patch
>
>
> Documentation for writeVLong in WritableUtils states that "For
>  -112 <= i <= 127, only one byte is used"
> Documentation for writeVInt states that "For -120 <= i <= 127, only one byte 
> is used"
> writeVInt calls internally writeVLong, so the ranges are the same for both 
> functions. 
> After examining the code, I see that the documentation that is at writeVLong 
> is correct.
> Documentation for writeVInt is therefore incorrect and should be fixed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MAPREDUCE-6496) Incorrect javadoc in WritableUtils.java

2015-10-05 Thread Jagadesh Kiran N (JIRA) 

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

Jagadesh Kiran N updated MAPREDUCE-6496:

Attachment: MAPREDUCE-6496-01.patch

Thanks [~ajisakaa] & [~mpl] for your reviews, I have executed the test cases 
for different combinations for vint and all values seems fall between  -113 and 
-116, or between -121 and -124.Changed the Same Please review

> Incorrect javadoc in WritableUtils.java
> ---
>
> Key: MAPREDUCE-6496
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6496
> Project: Hadoop Map/Reduce
>  Issue Type: Bug
>Affects Versions: 2.7.1
>Reporter: Martin Petricek
>Assignee: Jagadesh Kiran N
>Priority: Minor
> Attachments: MAPREDUCE-6496-00.patch, MAPREDUCE-6496-01.patch
>
>
> Documentation for writeVLong in WritableUtils states that "For
>  -112 <= i <= 127, only one byte is used"
> Documentation for writeVInt states that "For -120 <= i <= 127, only one byte 
> is used"
> writeVInt calls internally writeVLong, so the ranges are the same for both 
> functions. 
> After examining the code, I see that the documentation that is at writeVLong 
> is correct.
> Documentation for writeVInt is therefore incorrect and should be fixed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MAPREDUCE-6496) Incorrect javadoc in WritableUtils.java

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

[ 
https://issues.apache.org/jira/browse/MAPREDUCE-6496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14937740#comment-14937740
 ] 

Jagadesh Kiran N commented on MAPREDUCE-6496:
-

No changes done in Java Doc ,no tests are included.

> Incorrect javadoc in WritableUtils.java
> ---
>
> Key: MAPREDUCE-6496
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6496
> Project: Hadoop Map/Reduce
>  Issue Type: Bug
>Affects Versions: 2.7.1
>Reporter: Martin Petricek
>Assignee: Jagadesh Kiran N
>Priority: Minor
> Attachments: MAPREDUCE-6496-00.patch
>
>
> Documentation for writeVLong in WritableUtils states that "For
>  -112 <= i <= 127, only one byte is used"
> Documentation for writeVInt states that "For -120 <= i <= 127, only one byte 
> is used"
> writeVInt calls internally writeVLong, so the ranges are the same for both 
> functions. 
> After examining the code, I see that the documentation that is at writeVLong 
> is correct.
> Documentation for writeVInt is therefore incorrect and should be fixed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (MAPREDUCE-6496) Incorrect javadoc in WritableUtils.java

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

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

Jagadesh Kiran N reassigned MAPREDUCE-6496:
---

Assignee: Jagadesh Kiran N

> Incorrect javadoc in WritableUtils.java
> ---
>
> Key: MAPREDUCE-6496
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6496
> Project: Hadoop Map/Reduce
>  Issue Type: Bug
>Affects Versions: 2.7.1
>Reporter: Martin Petricek
>Assignee: Jagadesh Kiran N
>Priority: Minor
>
> Documentation for writeVLong in WritableUtils states that "For
>  -112 <= i <= 127, only one byte is used"
> Documentation for writeVInt states that "For -120 <= i <= 127, only one byte 
> is used"
> writeVInt calls internally writeVLong, so the ranges are the same for both 
> functions. 
> After examining the code, I see that the documentation that is at writeVLong 
> is correct.
> Documentation for writeVInt is therefore incorrect and should be fixed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MAPREDUCE-6496) Incorrect javadoc in WritableUtils.java

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

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

Jagadesh Kiran N updated MAPREDUCE-6496:

Attachment: MAPREDUCE-6496-00.patch

Attached the patch, [~mpl] Please review 

> Incorrect javadoc in WritableUtils.java
> ---
>
> Key: MAPREDUCE-6496
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6496
> Project: Hadoop Map/Reduce
>  Issue Type: Bug
>Affects Versions: 2.7.1
>Reporter: Martin Petricek
>Assignee: Jagadesh Kiran N
>Priority: Minor
> Attachments: MAPREDUCE-6496-00.patch
>
>
> Documentation for writeVLong in WritableUtils states that "For
>  -112 <= i <= 127, only one byte is used"
> Documentation for writeVInt states that "For -120 <= i <= 127, only one byte 
> is used"
> writeVInt calls internally writeVLong, so the ranges are the same for both 
> functions. 
> After examining the code, I see that the documentation that is at writeVLong 
> is correct.
> Documentation for writeVInt is therefore incorrect and should be fixed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MAPREDUCE-6496) Incorrect javadoc in WritableUtils.java

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

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

Jagadesh Kiran N updated MAPREDUCE-6496:

Status: Patch Available  (was: Open)

> Incorrect javadoc in WritableUtils.java
> ---
>
> Key: MAPREDUCE-6496
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6496
> Project: Hadoop Map/Reduce
>  Issue Type: Bug
>Affects Versions: 2.7.1
>Reporter: Martin Petricek
>Assignee: Jagadesh Kiran N
>Priority: Minor
> Attachments: MAPREDUCE-6496-00.patch
>
>
> Documentation for writeVLong in WritableUtils states that "For
>  -112 <= i <= 127, only one byte is used"
> Documentation for writeVInt states that "For -120 <= i <= 127, only one byte 
> is used"
> writeVInt calls internally writeVLong, so the ranges are the same for both 
> functions. 
> After examining the code, I see that the documentation that is at writeVLong 
> is correct.
> Documentation for writeVInt is therefore incorrect and should be fixed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

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

Jagadesh Kiran N commented on MAPREDUCE-6468:
-

[~ozawa] 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] [Commented] (MAPREDUCE-6468) Consistent log severity level guards and statements in MapReduce project

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

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

Jagadesh Kiran N commented on MAPREDUCE-6468:
-

[~ozawa] 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] [Commented] (MAPREDUCE-6468) Consistent log severity level guards and statements in MapReduce project

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

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

Jagadesh Kiran N commented on MAPREDUCE-6468:
-

Test case failures are not related to the Patch. [~ozawa] 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-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] [Commented] (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:comment-tabpanel=14736793#comment-14736793
 ] 

Jagadesh Kiran N commented on MAPREDUCE-6468:
-

No Findbugs in the Report, And the test case failures are not related to the 
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, 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 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)

[jira] [Commented] (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:comment-tabpanel=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, 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)

[jira] [Commented] (MAPREDUCE-6468) Consistent log severity level guards and statements

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

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

Jagadesh Kiran N commented on MAPREDUCE-6468:
-

Changes are related to Log level hence tests are not required

> Consistent log severity level guards and statements 
> 
>
> 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] [Moved] (MAPREDUCE-6468) Consistent log severity level guards and statements

2015-09-03 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 moved HADOOP-9995 to MAPREDUCE-6468:
-

Key: MAPREDUCE-6468  (was: HADOOP-9995)
Project: Hadoop Map/Reduce  (was: Hadoop Common)

> Consistent log severity level guards and statements 
> 
>
> 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
>
>
> 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] [Commented] (MAPREDUCE-6468) Consistent log severity level guards and statements

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

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

Jagadesh Kiran N commented on MAPREDUCE-6468:
-

Changes done are only in Map reduce hence moving the defect to Map Reduce

> Consistent log severity level guards and statements 
> 
>
> 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
>
>
> 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

2015-09-03 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-01.patch

Updating patch to Mapreduce ,[~rohithsharma] please review the same

> Consistent log severity level guards and statements 
> 
>
> 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] [Commented] (MAPREDUCE-6403) Fix typo in the usage of NNBench

2015-06-21 Thread Jagadesh Kiran N (JIRA) 

[ 
https://issues.apache.org/jira/browse/MAPREDUCE-6403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14595043#comment-14595043
 ] 

Jagadesh Kiran N commented on MAPREDUCE-6403:
-

HI the test cases failing at
  org.apache.hadoop.mapred.TestMiniMRClientCluster.testJob
  
org.apache.hadoop.mapred.TestReduceFetchFromPartialMem.testReduceFromPartialMem
  
org.apache.hadoop.mapred.TestReduceFetchFromPartialMem.testReduceFromPartialMem
 is not releated any of the changes done in the Patch.

 Fix typo in the usage of NNBench
 

 Key: MAPREDUCE-6403
 URL: https://issues.apache.org/jira/browse/MAPREDUCE-6403
 Project: Hadoop Map/Reduce
  Issue Type: Bug
  Components: documentation
Reporter: Akira AJISAKA
Assignee: Jagadesh Kiran N
Priority: Trivial
  Labels: newbie
 Attachments: MAPREDUCE-6403-00.patch


 Fix typo 'becnhmarks'.
 {code:title=NNBench.java}
   \t-baseDir base DFS path. default is /becnhmarks/NNBench.  +
   This is not mandatory\n +
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MAPREDUCE-6403) Fix typo in the usage of NNBench

2015-06-20 Thread Jagadesh Kiran N (JIRA) 

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

Jagadesh Kiran N updated MAPREDUCE-6403:

Attachment: MAPREDUCE-6403-00.patch

Thanks [~ajisakaa] for reporting the same, I have fixed the same please find 
the attached patch ,review the same

 Fix typo in the usage of NNBench
 

 Key: MAPREDUCE-6403
 URL: https://issues.apache.org/jira/browse/MAPREDUCE-6403
 Project: Hadoop Map/Reduce
  Issue Type: Bug
  Components: documentation
Reporter: Akira AJISAKA
Assignee: Jagadesh Kiran N
Priority: Trivial
  Labels: newbie
 Attachments: MAPREDUCE-6403-00.patch


 Fix typo 'becnhmarks'.
 {code:title=NNBench.java}
   \t-baseDir base DFS path. default is /becnhmarks/NNBench.  +
   This is not mandatory\n +
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MAPREDUCE-6403) Fix typo in the usage of NNBench

2015-06-20 Thread Jagadesh Kiran N (JIRA) 

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

Jagadesh Kiran N updated MAPREDUCE-6403:

Status: Patch Available  (was: Open)

 Fix typo in the usage of NNBench
 

 Key: MAPREDUCE-6403
 URL: https://issues.apache.org/jira/browse/MAPREDUCE-6403
 Project: Hadoop Map/Reduce
  Issue Type: Bug
  Components: documentation
Reporter: Akira AJISAKA
Assignee: Jagadesh Kiran N
Priority: Trivial
  Labels: newbie
 Attachments: MAPREDUCE-6403-00.patch


 Fix typo 'becnhmarks'.
 {code:title=NNBench.java}
   \t-baseDir base DFS path. default is /becnhmarks/NNBench.  +
   This is not mandatory\n +
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)