[
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)
