Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Sat, 31 Oct 2015 08:45:28 +0000 (UTC)
From: "Yi Liu (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.12654827.1372196677000.115639.1446281128616@Atlassian.JIRA>
In-Reply-To: <JIRA.12654827.1372196677000@Atlassian.JIRA>
References: <JIRA.12654827.1372196677000@Atlassian.JIRA>
 <JIRA.12654827.1372196677507@arcas>
Subject: [jira] [Comment Edited] (HDFS-4937) ReplicationMonitor can
 infinite-loop in BlockPlacementPolicyDefault#chooseRandom()
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Yi Liu edited comment on HDFS-4937 at 10/31/15 8:45 AM:
--------------------------------------------------------

I did consider the situation you mentioned, But I thought in real env the NN could find other racks/DNs if it has gone through enough (not all) number of nodes.  But I missed the fact that many tests may only contain few available DNs, and {{refreshCounter <= excludedNodes.size()}} will be true, also in real env this also may happen if total number of DNs is few.  So the patch should not be correct for these cases, revert them.


was (Author: hitliuyi):
I did consider the situation you mentioned, But I thought in real env the NN could find other racks/DNs if it has gone through enough number of nodes.  But I missed the fact that many tests may only contain few available DNs, and {{refreshCounter <= excludedNodes.size()}} will be true, also in real env this also may happen if total number of DNs is few.  So the patch should not be correct for these cases, revert them.

> ReplicationMonitor can infinite-loop in BlockPlacementPolicyDefault#chooseRandom()
> ----------------------------------------------------------------------------------
>
>                 Key: HDFS-4937
>                 URL: https://issues.apache.org/jira/browse/HDFS-4937
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: namenode
>    Affects Versions: 2.0.4-alpha, 0.23.8
>            Reporter: Kihwal Lee
>            Assignee: Kihwal Lee
>              Labels: BB2015-05-TBR
>             Fix For: 3.0.0, 2.7.2
>
>         Attachments: HDFS-4937.patch, HDFS-4937.v1.patch, HDFS-4937.v2.patch
>
>
> When a large number of nodes are removed by refreshing node lists, the network topology is updated. If the refresh happens at the right moment, the replication monitor thread may stuck in the while loop of {{chooseRandom()}}. This is because the cached cluster size is used in the terminal condition check of the loop. This usually happens when a block with a high replication factor is being processed. Since replicas/rack is also calculated beforehand, no node choice may satisfy the goodness criteria if refreshing removed racks. 
> All nodes will end up in the excluded list, but the size will still be less than the cached cluster size, so it will loop infinitely. This was observed in a production environment.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)