Wei-Chiu Chuang created HDFS-9599:
-------------------------------------
Summary: TestDecommissioningStatus.testDecommissionStatus
occasionally fails
Key: HDFS-9599
URL: https://issues.apache.org/jira/browse/HDFS-9599
Project: Hadoop HDFS
Issue Type: Bug
Components: namenode
Environment: Jenkins
Reporter: Wei-Chiu Chuang
Assignee: Wei-Chiu Chuang
>From test result of a recent jenkins nightly
>https://builds.apache.org/job/Hadoop-Hdfs-trunk/2663/testReport/junit/org.apache.hadoop.hdfs.server.namenode/TestDecommissioningStatus/testDecommissionStatus/
The test failed because the number of under replicated blocks is 4, instead of
3.
Looking at the log, there is a strayed block, which might have caused the
faillure:
{noformat}
2015-12-23 00:42:05,820 [Block report processor] INFO BlockStateChange
(BlockManager.java:processReport(2131)) - BLOCK* processReport:
blk_1073741825_1001 on node 127.0.0.1:57382 size 16384 does not belong to any
file
{noformat}
The block size 16384 suggests this is left over from the sibling test case
testDecommissionStatusAfterDNRestart. This can happen, because the same minidfs
cluster is reused between tests.
The test implementation should do a better job isolating tests.
Another case of failure is when the load factor comes into play, and a block
can not find sufficient data nodes to place replica. In this test, the runtime
should not consider load factor:
{noformat}
conf.setBoolean(DFSConfigKeys.DFS_NAMENODE_REPLICATION_CONSIDERLOAD_KEY, false);
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
