You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-issues@hadoop.apache.org by "Jason Lowe (JIRA)" <ji...@apache.org> on 2013/12/17 22:18:07 UTC
[jira] [Commented] (HDFS-5449) WebHdfs compatibility broken between
2.2 and 1.x / 23.x
[ https://issues.apache.org/jira/browse/HDFS-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13850920#comment-13850920 ]
Jason Lowe commented on HDFS-5449:
----------------------------------
Patch looks pretty good to me. One question about the toDatanodeInfo change: should we do anything different if ipAddr == null but colonIdx <= 0? Looks like we'll just NPE in that case. Granted we _shouldn't_ see that in practice, but I noticed that the old 0.23 DatanodeInfo code that parsed the name string would assume a default port of 50010 if it was missing. Wasn't sure if we should either default the port if missing in a similar manner or provide a more descriptive error than the resulting NPE if this does somehow happen.
> WebHdfs compatibility broken between 2.2 and 1.x / 23.x
> -------------------------------------------------------
>
> Key: HDFS-5449
> URL: https://issues.apache.org/jira/browse/HDFS-5449
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: Kihwal Lee
> Assignee: Kihwal Lee
> Priority: Blocker
> Attachments: HDFS-5449.patch, HDFS-5449.patch
>
>
> Similarly to HDFS-5403, getFileBlockLocations() fail between old (1.x, 0.23.x) and new (2.x), but this is worse since both directions won't work. This is caused by the removal of "name" field from the serialized json format of DatanodeInfo.
> 2.x namenode should include "name" (ip:port) in the response and 2.x webhdfs client should use "name", if "ipAddr" and "xferPort" don't exist in the response.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)