hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Masatake Iwasaki (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
Date Thu, 17 Sep 2015 04:26:45 GMT

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

Masatake Iwasaki commented on HDFS-8915:

bq. With this change I presume that test passes consistently on your local machine.

Yeah. {{mvn test -Dtest='TestFSNamesystem#testFSLockGetWaiterCount'}} failed within 5 tries
without the fix. TestNNHandlesCombinedBlockReport and TestWebHDFSOAuth2 succeeded on my local

> TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
> -------------------------------------------------------------------------
>                 Key: HDFS-8915
>                 URL: https://issues.apache.org/jira/browse/HDFS-8915
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: HDFS, test
>    Affects Versions: 2.8.0
>            Reporter: Anu Engineer
>            Assignee: Masatake Iwasaki
>         Attachments: HDFS-8915.001.patch
> This test was added as part of HDFS-8883, There is a race condition in the test and it
has failed *once* in the Apache Jenkins run.
> Here is the stack
> FAILED:  org.apache.hadoop.hdfs.server.namenode.TestFSNamesystem.testFSLockGetWaiterCount
> Error Message:
> Expected number of blocked thread not found expected:<3> but was:<1>
> Stack Trace:
> java.lang.AssertionError: Expected number of blocked thread not found expected:<3>
but was:<1>
> 	at org.junit.Assert.fail(Assert.java:88)
> 	at org.junit.Assert.failNotEquals(Assert.java:743)
> 	at org.junit.Assert.assertEquals(Assert.java:118)
> 	at org.junit.Assert.assertEquals(Assert.java:555)
> 	at org.apache.hadoop.hdfs.server.namenode.TestFSNamesystem.testFSLockGetWaiterCount(TestFSNamesystem.java:261)
> From cursory code reading , even though we call into readlock.lock() there is no guarantee
that our thread is put in the wait queue. A proposed fix could be to check for any thread
in the lock queue instead of all 3, or disable the test.
> It could also indicate an issue with the test infra-structure but any test open to variations
in result due to infra-structure issues creates noise in tests so we are better off fixing

This message was sent by Atlassian JIRA

View raw message