[jira] [Created] (HADOOP-13340) Compress Hadoop Archive output

2016-07-04 Thread Duc Le Tu (JIRA) 
Duc Le Tu created HADOOP-13340:
--

 Summary: Compress Hadoop Archive output
 Key: HADOOP-13340
 URL: https://issues.apache.org/jira/browse/HADOOP-13340
 Project: Hadoop Common
  Issue Type: New Feature
  Components: tools
Affects Versions: 2.5.0
Reporter: Duc Le Tu


Why Hadoop Archive tool cannot compress output like other map-reduce job? 
I used some options like -D mapreduce.output.fileoutputformat.compress=true -D 
mapreduce.output.fileoutputformat.compress.codec=org.apache.hadoop.io.compress.GzipCodec
 but it's not work. Did I wrong somewhere?

If not, please support option for compress output of Hadoop Archive tool, it's 
very neccessary for data retention for everyone (small files problem and 
compress data).



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

-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org

[jira] [Commented] (HADOOP-11361) Fix a race condition in MetricsSourceAdapter.updateJmxCache

2016-07-04 Thread Yongjun Zhang (JIRA) 

[ 
https://issues.apache.org/jira/browse/HADOOP-11361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15361883#comment-15361883
 ] 

Yongjun Zhang commented on HADOOP-11361:


Hi [~brahmareddy], Thank you and other folks for working on the issue here. 
Thanks [~ozawa] for pointing me to this jira since I ran into the same issue 
and reported  HADOOP-13339. 

I have a comment here:

https://issues.apache.org/jira/browse/HADOOP-13339?focusedCommentId=15361880=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15361880

Wonder if it makes sense to you guys.

Thanks.


> Fix a race condition in MetricsSourceAdapter.updateJmxCache
> ---
>
> Key: HADOOP-11361
> URL: https://issues.apache.org/jira/browse/HADOOP-11361
> Project: Hadoop Common
>  Issue Type: Bug
>Affects Versions: 2.4.1, 2.5.1, 2.6.0
>Reporter: Brahma Reddy Battula
>Assignee: Brahma Reddy Battula
> Attachments: HADOOP-111361-003.patch, HADOOP-11361-002.patch, 
> HADOOP-11361-004.patch, HADOOP-11361.patch, HDFS-7487.patch
>
>
> {noformat}
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.updateAttrCache(MetricsSourceAdapter.java:247)
>   at 
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.updateJmxCache(MetricsSourceAdapter.java:177)
>   at 
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.getAttribute(MetricsSourceAdapter.java:102)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
> {noformat}



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

-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org

[jira] [Commented] (HADOOP-13251) Authenticate with Kerberos credentials when renewing KMS delegation token

2016-07-04 Thread Xiao Chen (JIRA) 

[ 
https://issues.apache.org/jira/browse/HADOOP-13251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15361884#comment-15361884
 ] 

Xiao Chen commented on HADOOP-13251:


Hi [~aw],
Sorry for my late response, I was on PTO last week.

I feel this jira is orthogonal to the underlying kerberos implementations, so I 
would expect the current test cases cover each implementation by itself. Makes 
sense?

> Authenticate with Kerberos credentials when renewing KMS delegation token
> -
>
> Key: HADOOP-13251
> URL: https://issues.apache.org/jira/browse/HADOOP-13251
> Project: Hadoop Common
>  Issue Type: Bug
>  Components: kms
>Affects Versions: 2.8.0
>Reporter: Xiao Chen
>Assignee: Xiao Chen
> Fix For: 2.8.0
>
> Attachments: HADOOP-13251.01.patch, HADOOP-13251.02.patch, 
> HADOOP-13251.03.patch, HADOOP-13251.04.patch, HADOOP-13251.05.patch, 
> HADOOP-13251.06.patch, HADOOP-13251.07.patch, HADOOP-13251.08.patch, 
> HADOOP-13251.08.patch, HADOOP-13251.09.patch, HADOOP-13251.10.patch, 
> HADOOP-13251.innocent.patch
>
>
> Turns out KMS delegation token renewal feature (HADOOP-13155) does not work 
> well with client side impersonation.
> In a MR example, an end user (UGI:user) gets all kinds of DTs (with 
> renewer=yarn), and pass them to Yarn. Yarn's resource manager (UGI:yarn) then 
> renews these DTs as long as the MR jobs are running. But currently, the token 
> is used at the kms server side to decide the renewer, in which case is always 
> the token's owner. This ends up rejecting the renew request due to renewer 
> mismatch.



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

-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org

[jira] [Comment Edited] (HADOOP-13339) MetricsSourceAdapter#updateAttrCache may throw NPE due to NULL lastRecs

2016-07-04 Thread Yongjun Zhang (JIRA) 

[ 
https://issues.apache.org/jira/browse/HADOOP-13339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15361880#comment-15361880
 ] 

Yongjun Zhang edited comment on HADOOP-13339 at 7/5/16 1:38 AM:


Hi [~ozawa],

Thanks for pointing me to HADOOP-11361.

I was about to update here:

Per the trace stack I'm seeing:
{code}
Caused by: java.lang.NullPointerException
at 
org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.updateAttrCache(MetricsSourceAdapter.java:260)
at 
org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.updateJmxCache(MetricsSourceAdapter.java:184)
at 
org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.getMBeanInfo(MetricsSourceAdapter.java:155)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBeanInfo(DefaultMBeanServerInterceptor.java:1378)
{code}

The relevant code is

{code}
  private void updateJmxCache() {
boolean getAllMetrics = false;
synchronized(this) {
  if (Time.now() - jmxCacheTS >= jmxCacheTTL) {
// temporarilly advance the expiry while updating the cache
jmxCacheTS = Time.now() + jmxCacheTTL;
// lastRecs might have been set to an object already by another thread.
// Track the fact that lastRecs has been reset once to make sure refresh
// is correctly triggered.
if (lastRecsCleared) {
  getAllMetrics = true;
  lastRecsCleared = false;
}
  }
  else {
return;
  }
}

if (getAllMetrics) {
  MetricsCollectorImpl builder = new MetricsCollectorImpl();
  getMetrics(builder, true); <== This is where lastRecs is created/assigned 
non-NULL
}

synchronized(this) {
  updateAttrCache(); <=== This is where the NPE happened
  if (getAllMetrics) {
updateInfoCache();
  }
  jmxCacheTS = Time.now();
  lastRecs = null;  // in case regular interval update is not running <==  
This is where lastRecs assigned NULL
  lastRecsCleared = true;
}
  }
{code}

If one thread enters the above method with {{Time.now() - jmxCacheTS >= 
jmxCacheTTL}} being false, then {{getAllMetrics}} will continue to be false, 
then when {{updateAttrCache()}} is called, it will hit NULL {{lastRecs}}

Even a single thread like this would hit the issue. So it doesn't seem a pure 
synchronization issue.  And the code prior to HADOOP-12482 appear to have the 
same issue.

Brief look at HADOOP-12482, the logic seems fine, except the hole pointed out 
here. While we need to examine the synchronization a bit further, have a 
checking in {{MetricsSourceAdapter#updateAttrCache}} (so not to access it when 
lastRecs is NULL) seems reasonable.

What do you think?

Thanks.




was (Author: yzhangal):
Hi [~ozawa],

Thanks for pointing me to HADOOP-11361.

I was about to update here:

Per the trace stack I'm seeing:
{code}
Caused by: java.lang.NullPointerException
at 
org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.updateAttrCache(MetricsSourceAdapter.java:260)
at 
org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.updateJmxCache(MetricsSourceAdapter.java:184)
at 
org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.getMBeanInfo(MetricsSourceAdapter.java:155)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBeanInfo(DefaultMBeanServerInterceptor.java:1378)
{code}

The relevant code is

{code}
  private void updateJmxCache() {
boolean getAllMetrics = false;
synchronized(this) {
  if (Time.now() - jmxCacheTS >= jmxCacheTTL) {
// temporarilly advance the expiry while updating the cache
jmxCacheTS = Time.now() + jmxCacheTTL;
// lastRecs might have been set to an object already by another thread.
// Track the fact that lastRecs has been reset once to make sure refresh
// is correctly triggered.
if (lastRecsCleared) {
  getAllMetrics = true;
  lastRecsCleared = false;
}
  }
  else {
return;
  }
}

if (getAllMetrics) {
  MetricsCollectorImpl builder = new MetricsCollectorImpl();
  getMetrics(builder, true); <== This is where lastRecs is created/assigned 
non-NULL
}

synchronized(this) {
  updateAttrCache(); <=== This is where the NPE happened
  if (getAllMetrics) {
updateInfoCache();
  }
  jmxCacheTS = Time.now();
  lastRecs = null;  // in case regular interval update is not running <==  
This is where lastRecs assigned NULL
  lastRecsCleared = true;
}
  }
{code}

If one thread enters the above method with {{Time.now() - jmxCacheTS >= 
jmxCacheTTL}} being false, then {{getAllMetrics}} will continue to be false, 
then when {{updateAttrCache()}} is called, it will hit NULL {{lastRecs}}

Even a single thread like this would hit the issue. So it doesn't seem a pure 
synchronization issue.  And the code prior to HADOOP-12482 appear to have the

[jira] [Commented] (HADOOP-13339) MetricsSourceAdapter#updateAttrCache may throw NPE due to NULL lastRecs

2016-07-04 Thread Yongjun Zhang (JIRA) 

[ 
https://issues.apache.org/jira/browse/HADOOP-13339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15361880#comment-15361880
 ] 

Yongjun Zhang commented on HADOOP-13339:


Hi [~ozawa],

Thanks for pointing me to HADOOP-11361.

I was about to update here:

Per the trace stack I'm seeing:
{code}
Caused by: java.lang.NullPointerException
at 
org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.updateAttrCache(MetricsSourceAdapter.java:260)
at 
org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.updateJmxCache(MetricsSourceAdapter.java:184)
at 
org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.getMBeanInfo(MetricsSourceAdapter.java:155)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBeanInfo(DefaultMBeanServerInterceptor.java:1378)
{code}

The relevant code is

{code}
  private void updateJmxCache() {
boolean getAllMetrics = false;
synchronized(this) {
  if (Time.now() - jmxCacheTS >= jmxCacheTTL) {
// temporarilly advance the expiry while updating the cache
jmxCacheTS = Time.now() + jmxCacheTTL;
// lastRecs might have been set to an object already by another thread.
// Track the fact that lastRecs has been reset once to make sure refresh
// is correctly triggered.
if (lastRecsCleared) {
  getAllMetrics = true;
  lastRecsCleared = false;
}
  }
  else {
return;
  }
}

if (getAllMetrics) {
  MetricsCollectorImpl builder = new MetricsCollectorImpl();
  getMetrics(builder, true); <== This is where lastRecs is created/assigned 
non-NULL
}

synchronized(this) {
  updateAttrCache(); <=== This is where the NPE happened
  if (getAllMetrics) {
updateInfoCache();
  }
  jmxCacheTS = Time.now();
  lastRecs = null;  // in case regular interval update is not running <==  
This is where lastRecs assigned NULL
  lastRecsCleared = true;
}
  }
{code}

If one thread enters the above method with {{Time.now() - jmxCacheTS >= 
jmxCacheTTL}} being false, then {{getAllMetrics}} will continue to be false, 
then when {{updateAttrCache()}} is called, it will hit NULL {{lastRecs}}

Even a single thread like this would hit the issue. So it doesn't seem a pure 
synchronization issue.  And the code prior to HADOOP-12482 appear to have the 
same issue.

Brief look at HADOOP-12482, the logic seems fine, except the hole pointed out 
here. While we need to examine the synchronization a bit further, have a 
checking in MetricsSourceAdapter#updateAttrCache (so not to access it when 
lastRecs is NULL) seems reasonable.

What do you think?

Thanks.



> MetricsSourceAdapter#updateAttrCache may throw NPE due to NULL lastRecs
> ---
>
> Key: HADOOP-13339
> URL: https://issues.apache.org/jira/browse/HADOOP-13339
> Project: Hadoop Common
>  Issue Type: Bug
>Reporter: Yongjun Zhang
>Assignee: Yongjun Zhang
>
> The for loop below may find lastRecs NULL
> {code}
>   private int updateAttrCache() {
> LOG.debug("Updating attr cache...");
> int recNo = 0;
> int numMetrics = 0;
> for (MetricsRecordImpl record : lastRecs) {
>   for (MetricsTag t : record.tags()) {
> setAttrCacheTag(t, recNo);
> ++numMetrics;
>   }
>   for (AbstractMetric m : record.metrics()) {
> setAttrCacheMetric(m, recNo);
> ++numMetrics;
>   }
>   ++recNo;
> }
> LOG.debug("Done. # tags & metrics="+ numMetrics);
> return numMetrics;
>   }
> {code}
> and throws NPE. 



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

-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org

[jira] [Commented] (HADOOP-11361) Fix a race condition in MetricsSourceAdapter.updateJmxCache

2016-07-04 Thread Hadoop QA (JIRA) 

[ 
https://issues.apache.org/jira/browse/HADOOP-11361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15361837#comment-15361837
 ] 

Hadoop QA commented on HADOOP-11361:


| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
21s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green}  0m  
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red}  0m  
0s{color} | {color:red} 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} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  7m 
12s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  7m  
8s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
22s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green}  0m 
56s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
12s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  1m 
22s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
46s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  0m 
40s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  6m 
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  6m 
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green}  0m 
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  1m 
33s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
45s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}  7m 58s{color} 
| {color:red} hadoop-common in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
20s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 39m 19s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.ha.TestZKFailoverController |
\\
\\
|| Subsystem || Report/Notes ||
| Docker |  Image:yetus/hadoop:85209cc |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12797703/HADOOP-11361-004.patch
 |
| JIRA Issue | HADOOP-11361 |
| Optional Tests |  asflicense  compile  javac  javadoc  mvninstall  mvnsite  
unit  findbugs  checkstyle  |
| uname | Linux 8abd4158cf51 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed 
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | /testptch/hadoop/patchprocess/precommit/personality/provided.sh 
|
| git revision | trunk / 8b4b525 |
| Default Java | 1.8.0_91 |
| findbugs | v3.0.0 |
| unit | 
https://builds.apache.org/job/PreCommit-HADOOP-Build/9922/artifact/patchprocess/patch-unit-hadoop-common-project_hadoop-common.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HADOOP-Build/9922/testReport/ |
| modules | C: hadoop-common-project/hadoop-common U: 
hadoop-common-project/hadoop-common |
| Console output | 
https://builds.apache.org/job/PreCommit-HADOOP-Build/9922/console |
| Powered by | Apache Yetus 0.4.0-SNAPSHOT   http://yetus.apache.org |


This message was automatically generated.



> Fix a race condition in MetricsSourceAdapter.updateJmxCache
> ---
>
> Key: HADOOP-11361
> URL: https://issues.apache.org/jira/browse/HADOOP-11361
> Project: Hadoop

[jira] [Commented] (HADOOP-11361) Fix a race condition in MetricsSourceAdapter.updateJmxCache

2016-07-04 Thread Tsuyoshi Ozawa (JIRA) 

[ 
https://issues.apache.org/jira/browse/HADOOP-11361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15361826#comment-15361826
 ] 

Tsuyoshi Ozawa commented on HADOOP-11361:
-

Sorry for the delay. Reviewing.

> Fix a race condition in MetricsSourceAdapter.updateJmxCache
> ---
>
> Key: HADOOP-11361
> URL: https://issues.apache.org/jira/browse/HADOOP-11361
> Project: Hadoop Common
>  Issue Type: Bug
>Affects Versions: 2.4.1, 2.5.1, 2.6.0
>Reporter: Brahma Reddy Battula
>Assignee: Brahma Reddy Battula
> Attachments: HADOOP-111361-003.patch, HADOOP-11361-002.patch, 
> HADOOP-11361-004.patch, HADOOP-11361.patch, HDFS-7487.patch
>
>
> {noformat}
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.updateAttrCache(MetricsSourceAdapter.java:247)
>   at 
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.updateJmxCache(MetricsSourceAdapter.java:177)
>   at 
> org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.getAttribute(MetricsSourceAdapter.java:102)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
> {noformat}



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

-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org

[jira] [Resolved] (HADOOP-13339) MetricsSourceAdapter#updateAttrCache may throw NPE due to NULL lastRecs

2016-07-04 Thread Tsuyoshi Ozawa (JIRA) 

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

Tsuyoshi Ozawa resolved HADOOP-13339.
-
Resolution: Duplicate

Dup of HADOOP-11361. Closing this.

> MetricsSourceAdapter#updateAttrCache may throw NPE due to NULL lastRecs
> ---
>
> Key: HADOOP-13339
> URL: https://issues.apache.org/jira/browse/HADOOP-13339
> Project: Hadoop Common
>  Issue Type: Bug
>Reporter: Yongjun Zhang
>Assignee: Yongjun Zhang
>
> The for loop below may find lastRecs NULL
> {code}
>   private int updateAttrCache() {
> LOG.debug("Updating attr cache...");
> int recNo = 0;
> int numMetrics = 0;
> for (MetricsRecordImpl record : lastRecs) {
>   for (MetricsTag t : record.tags()) {
> setAttrCacheTag(t, recNo);
> ++numMetrics;
>   }
>   for (AbstractMetric m : record.metrics()) {
> setAttrCacheMetric(m, recNo);
> ++numMetrics;
>   }
>   ++recNo;
> }
> LOG.debug("Done. # tags & metrics="+ numMetrics);
> return numMetrics;
>   }
> {code}
> and throws NPE. 



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

-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org

[jira] [Created] (HADOOP-13339) MetricsSourceAdapter#updateAttrCache may throw NPE due to NULL lastRecs

2016-07-04 Thread Yongjun Zhang (JIRA) 
Yongjun Zhang created HADOOP-13339:
--

 Summary: MetricsSourceAdapter#updateAttrCache may throw NPE due to 
NULL lastRecs
 Key: HADOOP-13339
 URL: https://issues.apache.org/jira/browse/HADOOP-13339
 Project: Hadoop Common
  Issue Type: Bug
Reporter: Yongjun Zhang
Assignee: Yongjun Zhang


The for loop below may find lastRecs NULL
{code}
  private int updateAttrCache() {
LOG.debug("Updating attr cache...");
int recNo = 0;
int numMetrics = 0;
for (MetricsRecordImpl record : lastRecs) {
  for (MetricsTag t : record.tags()) {
setAttrCacheTag(t, recNo);
++numMetrics;
  }
  for (AbstractMetric m : record.metrics()) {
setAttrCacheMetric(m, recNo);
++numMetrics;
  }
  ++recNo;
}
LOG.debug("Done. # tags & metrics="+ numMetrics);
return numMetrics;
  }
{code}
and throws NPE. 





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

-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org

[jira] [Updated] (HADOOP-13329) Dockerfile doesn't work on Linux/ppc

2016-07-04 Thread Amir Sanjar (JIRA) 

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

Amir Sanjar updated HADOOP-13329:
-
Attachment: HADOOP-13329.patch

> Dockerfile doesn't work on Linux/ppc
> 
>
> Key: HADOOP-13329
> URL: https://issues.apache.org/jira/browse/HADOOP-13329
> Project: Hadoop Common
>  Issue Type: Bug
>  Components: build
>Affects Versions: 3.0.0-alpha1
>Reporter: Allen Wittenauer
>Assignee: Amir Sanjar
> Attachments: HADOOP-13329.patch
>
>
> We need to rework how the Dockerfile is built to support both Linux/x86 and 
> Linux/PowerPC.



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

-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org

[jira] [Commented] (HADOOP-13329) Dockerfile doesn't work on Linux/ppc

2016-07-04 Thread Amir Sanjar (JIRA) 

[ 
https://issues.apache.org/jira/browse/HADOOP-13329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15361681#comment-15361681
 ] 

Amir Sanjar commented on HADOOP-13329:
--

submitted patch for review 

> Dockerfile doesn't work on Linux/ppc
> 
>
> Key: HADOOP-13329
> URL: https://issues.apache.org/jira/browse/HADOOP-13329
> Project: Hadoop Common
>  Issue Type: Bug
>  Components: build
>Affects Versions: 3.0.0-alpha1
>Reporter: Allen Wittenauer
>Assignee: Amir Sanjar
> Attachments: HADOOP-13329.patch
>
>
> We need to rework how the Dockerfile is built to support both Linux/x86 and 
> Linux/PowerPC.



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

-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org