Return-Path: X-Original-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Delivered-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9FBCAD3F0 for ; Thu, 30 Aug 2012 23:25:08 +0000 (UTC) Received: (qmail 72905 invoked by uid 500); 30 Aug 2012 23:25:08 -0000 Delivered-To: apmail-hadoop-hdfs-issues-archive@hadoop.apache.org Received: (qmail 72865 invoked by uid 500); 30 Aug 2012 23:25:08 -0000 Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hdfs-issues@hadoop.apache.org Delivered-To: mailing list hdfs-issues@hadoop.apache.org Received: (qmail 72814 invoked by uid 99); 30 Aug 2012 23:25:08 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Aug 2012 23:25:08 +0000 Date: Fri, 31 Aug 2012 10:25:08 +1100 (NCT) From: "Todd Lipcon (JIRA)" To: hdfs-issues@hadoop.apache.org Message-ID: <888208615.19109.1346369108315.JavaMail.jiratomcat@arcas> Subject: [jira] [Created] (HDFS-3876) NN should not RPC to self to find trash defaults (causes deadlock) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 Todd Lipcon created HDFS-3876: --------------------------------- Summary: NN should not RPC to self to find trash defaults (causes deadlock) Key: HDFS-3876 URL: https://issues.apache.org/jira/browse/HDFS-3876 Project: Hadoop HDFS Issue Type: Bug Components: name-node Affects Versions: 3.0.0, 2.2.0-alpha Reporter: Todd Lipcon Priority: Blocker When transitioning a SBN to active, I ran into the following situation: - the TrashPolicy first gets loaded by an IPC Server Handler thread. The {{initialize}} function then tries to make an RPC to the same node to find out the defaults. - This is happening inside the NN write lock (since it's part of the active initialization). Hence, all of the other handler threads are already blocked waiting to get the NN lock. - Since no handler threads are free, the RPC blocks forever and the NN never enters active state. We need to have a general policy that the NN should never make RPCs to itself for any reason, due to potential for deadlocks like this. -- 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