hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anu Engineer (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
Date Tue, 18 Aug 2015 17:22:45 GMT

     [ https://issues.apache.org/jira/browse/HDFS-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Anu Engineer updated HDFS-8915:
-------------------------------
    Description: 
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
it.


  was:
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 code 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
it.



> 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
>    Affects Versions: 2.8.0
>            Reporter: Anu Engineer
>            Assignee: Anu Engineer
>
> 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
it.



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

Mime
View raw message