Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Wed, 28 Aug 2013 22:28:51 +0000 (UTC)
From: "Kihwal Lee (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.12666022.1377728816488.50053.1377728931689@arcas>
In-Reply-To: <JIRA.12666022.1377728816488@arcas>
References: <JIRA.12666022.1377728816488@arcas>
Subject: [jira] [Created] (HDFS-5142) Namenode crashes with NPE in
 ReplicationMonitor
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Kihwal Lee created HDFS-5142:
--------------------------------

             Summary: 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: 0.23.9, 2.1.0-beta
            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