hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron T. Myers (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HDFS-5403) WebHdfs client cannot communicate with older WebHdfs servers post HDFS-5306
Date Wed, 23 Oct 2013 05:57:43 GMT

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

Aaron T. Myers updated HDFS-5403:

    Attachment: HDFS-5403.patch

I'm pretty confident the eclipse failure was unrelated to this change.

The findbugs warning was just using "new Long(0)" instead of "0l". The difference between
this patch and the last is just the following:

diff --git hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/web/JsonUtil.java
index 0238469..db4adc5 100644
--- hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/web/JsonUtil.java
+++ hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/web/JsonUtil.java
@@ -304,7 +304,7 @@ static DatanodeInfo toDatanodeInfo(final Map<?, ?> m) {
     Object infoSecurePort = m.get("infoSecurePort");
     if (infoSecurePort == null) {
-      infoSecurePort = new Long(0); // same as the default value in hdfs.proto
+      infoSecurePort = 0l; // same as the default value in hdfs.proto
     return new DatanodeInfo(

I'll commit this based on Andrew's +1 if Jenkins comes back clean.

> WebHdfs client cannot communicate with older WebHdfs servers post HDFS-5306
> ---------------------------------------------------------------------------
>                 Key: HDFS-5403
>                 URL: https://issues.apache.org/jira/browse/HDFS-5403
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: webhdfs
>    Affects Versions: 2.2.0
>            Reporter: Aaron T. Myers
>            Assignee: Aaron T. Myers
>         Attachments: HDFS-5403.patch, HDFS-5403.patch
> HDFS-5306 introduced the field infoSecurePort to the DatanodeIDProto PB definition and
made it optional for compatibility purposes. However, we don't correctly the handle the case
when this field is not present when deserializing the response from a WebHdfs request. This
results in an NPE at the client when this occurs.

This message was sent by Atlassian JIRA

View raw message