[
https://issues.apache.org/jira/browse/HDFS-3902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13450768#comment-13450768
]
Andy Isaacson commented on HDFS-3902:
-------------------------------------
Since HDFS-3828 fixed the block scanner to not repeatedly rescan small
blockpools, the following test in TestDatanodeBlockScanner times out after 13
minutes in {{waitReplication}}:
{code}
207 assertTrue(MiniDFSCluster.corruptReplica(0, block));
208 assertTrue(MiniDFSCluster.corruptReplica(1, block));
209 assertTrue(MiniDFSCluster.corruptReplica(2, block));
...
219 // We now have the blocks to be marked as corrupt and we get back all
220 // its replicas
221 DFSTestUtil.waitReplication(fs, file1, (short)3);
222 assertTrue(DFSTestUtil.allBlockReplicasCorrupt(cluster, file1, 0));
{code}
That assertion seems very odd to me: it claims that a replication=3 block with
two corrupt replicas should report 1 location, but once we corrupt the third
replica the block should report all three (corrupt!) locations.
While validating this test regression, I found that TestDatanodeBlockScanner
varies its completion time between 1.5 and 12 minutes when run under {{mvn
test}}.
> TestDatanodeBlockScanner is flaky, broke entirely after HDFS-3828
> -----------------------------------------------------------------
>
> Key: HDFS-3902
> URL: https://issues.apache.org/jira/browse/HDFS-3902
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 2.1.0-alpha
> Reporter: Andy Isaacson
> Assignee: Andy Isaacson
> Priority: Minor
>
> Since HDFS-3828 fixed the block scanner to not repeatedly rescan small
> blockpools, TestDatanodeBlockScanner times out after 13 minutes in
> {{waitReplication.
--
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
