[
https://issues.apache.org/jira/browse/HDFS-5077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13745126#comment-13745126
]
Plamen Jeliazkov commented on HDFS-5077:
----------------------------------------
In the event that this happens I see two possible actions:
1) Throw an IOException (maybe a new type of exception that extends IO? Not
sure.) over the RPC and have DataNode re-attempt recovery if caught.
2) We skip that null target and continue with the remaining others; the Block
will be under-replicated for a short while. If all targets are null though,
(very rare, but still possible) then we will have to again resort to doing #1
anyway.
Any ideas / preferences?
> NPE in FSNamesystem.commitBlockSynchronization()
> ------------------------------------------------
>
> Key: HDFS-5077
> URL: https://issues.apache.org/jira/browse/HDFS-5077
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
> Affects Versions: 2.0.5-alpha
> Reporter: Konstantin Shvachko
> Assignee: Plamen Jeliazkov
>
> NN starts a block recovery, which will synchronize block replicas on
> different DNs. In the end one of DNs will report the list of the nodes
> containing the consistent replicas to the NN via commitBlockSynchronization()
> call. The NPE happens if just before processing commitBlockSynchronization()
> NN removes from active one of DNs that are then reported in the call.
--
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