You are viewing a plain text version of this content. The canonical link for it is here.

Posted to hdfs-dev@hadoop.apache.org by "Kihwal Lee (JIRA)" <ji...@apache.org> on 2013/08/29 23:27:52 UTC

[jira] [Resolved] (HDFS-5142) Namenode crashes with NPE in ReplicationMonitor

     [ https://issues.apache.org/jira/browse/HDFS-5142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kihwal Lee resolved HDFS-5142.
------------------------------

    Resolution: Duplicate

Ahhh. I thought it looked familiar. I did even commented on HDFS-4482.
                
> Namenode crashes with NPE in ReplicationMonitor
> -----------------------------------------------
>
>                 Key: HDFS-5142
>                 URL: https://issues.apache.org/jira/browse/HDFS-5142
>             Project: Hadoop HDFS
>          Issue Type: Bug
>    Affects Versions: 2.1.0-beta, 0.23.9
>            Reporter: Kihwal Lee
>            Priority: Critical
>
> When ReplicationMonitor creates and adds a replication work for a block, its INodeFile (0.23) or BlockCollection (2.x) is recorded. This is done under the FSN write lock, but the actual chooseTarget() call is made outside the lock.
> When chooseTarget() is called, FSDirectory#getFullPathName() ends up getting called. If the INode was unlinked from its parents after ReplicationMonitor releasing the lock (e.g. delete), this call genetates NPE and crashes the name node. 
> Path name is actually unused in the existing block placement policy modules. But private implementations might use it. It will be nice if we can avoid calling getFullPathName() at all here.

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