hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zhe Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-7225) Failed DataNode lookup can crash NameNode with NullPointerException
Date Fri, 17 Oct 2014 18:09:34 GMT

    [ https://issues.apache.org/jira/browse/HDFS-7225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14175327#comment-14175327

Zhe Zhang commented on HDFS-7225:

[~andrew.wang] Thanks for reviewing. 

bq. I also wonder why we have this inconsistency in the first place in InvalidateBlocks. Isn't
a better fix to properly update InvalidateBlocks when the set of DNs changes? I believe this
is how UnderReplicatedBlocks works, and I think generally we expect the internal state of
the active NN to be consistent.

The root cause of this inconsistency is similar to that of HDFS-6289, i.e., a DN restarts
with a reformatted (or new) volume. Thus a different {{datanodeUuid}} is registered for an
existing transfer address, replacing the existing entry in {{datanodeMap}}. Therefore when
a block invalidation request is scheduled, the DN lookup (using an old {{datanodeUuid}}) could
return null. 

Here's what I think this situation should be handled:
# When a DN lookup ({{datanodeManager.getDatanode(dn)}}) returns null in {{invalidateWorkForOneNode}},
we know this DN has been registered with a newer {{datanodeUuid}}. Skip the block invalidation
work on this DN for this time.
#* We should keep the block invalidation work under the old {{datanodeUuid}} for a certain
amount of time so they still have a chance to be executed if the old volume is attached and
registered again in the future
# Count the number of times that a DN has been skipped in block invalidation work. If it's
above a certain threshold, clear all entries in {{InvalidateBlocks}} under this DN. 
#* In the very rare case where a volume comes back after a long time, we should just wipe
out all blocks on it ([~andrew.wang] do you know if HDFS is already doing it?)
# To reduce the chance of going into this situation in the first place, we should improve
the ordering of executing invalidation and replication tasks (HDFS-7211)

> Failed DataNode lookup can crash NameNode with NullPointerException
> -------------------------------------------------------------------
>                 Key: HDFS-7225
>                 URL: https://issues.apache.org/jira/browse/HDFS-7225
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: namenode
>    Affects Versions: 2.6.0
>            Reporter: Zhe Zhang
>            Assignee: Zhe Zhang
>         Attachments: HDFS-7225-v1.patch
> {{BlockManager#invalidateWorkForOneNode}} looks up a DataNode by the {{datanodeUuid}}
and passes the resultant {{DatanodeDescriptor}} to {{InvalidateBlocks#invalidateWork}}. However,
if a wrong or outdated {{datanodeUuid}} is used, a null pointer will be passed to {{invalidateWork}}
which will use it to lookup in a {{TreeMap}}. Since the key type is {{DatanodeDescriptor}},
key comparison is based on the IP address. A null key will crash the NameNode with an NPE.

This message was sent by Atlassian JIRA

View raw message