[jira] [Updated] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
[ https://issues.apache.org/jira/browse/HDFS-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang updated HDFS-8915: -- Fix Version/s: (was: 3.0.0-alpha2) 3.0.0-alpha1 > 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: test >Affects Versions: 2.8.0 >Reporter: Anu Engineer >Assignee: Masatake Iwasaki >Priority: Minor > Fix For: 2.7.4, 3.0.0-alpha1 > > Attachments: HDFS-8915.001.patch, HDFS-8915.002.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 it. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Updated] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
[ https://issues.apache.org/jira/browse/HDFS-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kihwal Lee updated HDFS-8915: - Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 3.0.0-alpha2 2.7.4 Status: Resolved (was: Patch Available) Committed to trunk, branch-2, branch-2.8 and branch-2.7. Thanks for the patch [~iwasakims]. > 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: test >Affects Versions: 2.8.0 >Reporter: Anu Engineer >Assignee: Masatake Iwasaki >Priority: Minor > Fix For: 2.7.4, 3.0.0-alpha2 > > Attachments: HDFS-8915.001.patch, HDFS-8915.002.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 it. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Updated] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
[ https://issues.apache.org/jira/browse/HDFS-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsz Wo Nicholas Sze updated HDFS-8915: -- Priority: Minor (was: Major) Component/s: (was: HDFS) > 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: test >Affects Versions: 2.8.0 >Reporter: Anu Engineer >Assignee: Masatake Iwasaki >Priority: Minor > Attachments: HDFS-8915.001.patch, HDFS-8915.002.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 it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
[
https://issues.apache.org/jira/browse/HDFS-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masatake Iwasaki updated HDFS-8915:
---
Attachment: HDFS-8915.002.patch
Thanks for checking.
HDFS-9139 added fix for the same purpose.
{code}
Thread.sleep(10); // Lets all threads get BLOCKED
{code}
Though the difference is just doing retry or not, I attached rebased patch.
> 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, HDFS-8915.002.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 it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
[ https://issues.apache.org/jira/browse/HDFS-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Loughran updated HDFS-8915: - Status: Open (was: Patch Available) > 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 it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
[ https://issues.apache.org/jira/browse/HDFS-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Loughran updated HDFS-8915: - Status: Patch Available (was: Open) just tried to apply the patch to branch-2 and it failed. resubmitting > 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 it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
[ https://issues.apache.org/jira/browse/HDFS-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masatake Iwasaki updated HDFS-8915: --- Component/s: test > 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 it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
[ https://issues.apache.org/jira/browse/HDFS-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masatake Iwasaki updated HDFS-8915: --- Attachment: HDFS-8915.001.patch I added retry for checking. > 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 it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
[ https://issues.apache.org/jira/browse/HDFS-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masatake Iwasaki updated HDFS-8915: --- Status: Patch Available (was: Reopened) > 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 it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
[ 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)
