[
https://issues.apache.org/jira/browse/HDFS-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13472558#comment-13472558
]
Daryn Sharp commented on HDFS-3224:
-----------------------------------
Suresh, it's that {{Hosts2NodesMap}} is internally decided on how it will key
the node in the map. Now the caller assumes that it knows how the node is
keyed when fetching the node. Two possible approaches to decouple them are: 1)
the caller specifies the map key for the node, and again specifies the same key
when fetching a node. Or the node is passed to the fetch so {{Hosts2NodesMap}}
can extract the same key as it did when adding the node to the map.
It's kind of the same situation where the {{TokenCache}} assumed it knew how
the fs token would be keyed in the {{Credentials}}. When the assumption went
out of sync in some cases, it caused extra tokens to be fetched. In this case
it would confuse the node manager as to whether the node is new or a
replacement.
> Bug in check for DN re-registration with different storage ID
> -------------------------------------------------------------
>
> Key: HDFS-3224
> URL: https://issues.apache.org/jira/browse/HDFS-3224
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: Eli Collins
> Assignee: Jason Lowe
> Priority: Minor
> Attachments: HDFS-3224.patch, HDFS-3224.patch
>
>
> DatanodeManager#registerDatanode checks the host to node map using an IP:port
> key, however the map is keyed on IP, so this check will always fail. It's
> performing the check to determine if a DN with the same IP and storage ID has
> already registered, and if so to remove this DN from the map and indicate
> that eg it's no longer hosting these blocks. This bug has been here forever.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
