[jira] [Commented] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
[ https://issues.apache.org/jira/browse/HDFS-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15879143#comment-15879143 ] Xiao Chen commented on HDFS-8915: - Thanks for the fix. Linking HDFS-8883 here to make it more explicit. > 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.15#6346) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
[ https://issues.apache.org/jira/browse/HDFS-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15439251#comment-15439251 ] Hudson commented on HDFS-8915: -- SUCCESS: Integrated in Jenkins build Hadoop-trunk-Commit #10354 (See [https://builds.apache.org/job/Hadoop-trunk-Commit/10354/]) HDFS-8915. TestFSNamesystem.testFSLockGetWaiterCount fails (kihwal: rev 13fb1b50e608558b2970184908ee5b9fcd7eb7b6) * (edit) hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFSNamesystem.java > 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] [Commented] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
[
https://issues.apache.org/jira/browse/HDFS-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15439196#comment-15439196
]
Hadoop QA commented on HDFS-8915:
-
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 7s{color}
| {color:red} HDFS-8915 does not apply to trunk. Rebase required? Wrong Branch?
See https://wiki.apache.org/hadoop/HowToContribute for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HDFS-8915 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12766477/HDFS-8915.002.patch |
| Console output |
https://builds.apache.org/job/PreCommit-HDFS-Build/16549/console |
| Powered by | Apache Yetus 0.4.0-SNAPSHOT http://yetus.apache.org |
This message was automatically generated.
> 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)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
[
https://issues.apache.org/jira/browse/HDFS-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15439180#comment-15439180
]
Kihwal Lee commented on HDFS-8915:
--
{{testFSLockGetWaiterCount}} is very flaky in branch-2.7 for me and this patch
seems to fix it.
{{GenericTestUtils.waitFor()}} is certainly preferred over simple sleep.
+1
> 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)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
[
https://issues.apache.org/jira/browse/HDFS-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15209747#comment-15209747
]
Hadoop QA commented on HDFS-8915:
-
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 11s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
54s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 38s
{color} | {color:green} trunk passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 43s
{color} | {color:green} trunk passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
21s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 53s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
57s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 5s
{color} | {color:green} trunk passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 48s
{color} | {color:green} trunk passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
46s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 40s
{color} | {color:green} the patch passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 40s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
18s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 49s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
12s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
10s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 3s
{color} | {color:green} the patch passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 40s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 57m 9s {color}
| {color:red} hadoop-hdfs in the patch failed with JDK v1.8.0_74. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 54m 24s {color}
| {color:red} hadoop-hdfs in the patch failed with JDK v1.7.0_95. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
21s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 136m 56s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0_74 Failed junit tests | hadoop.hdfs.server.namenode.TestEditLog |
| | hadoop.hdfs.server.datanode.fsdataset.impl.TestFsDatasetImpl |
| JDK v1.7.0_95 Failed junit tests | hadoop.hdfs.TestEncryptionZones |
| | hadoop.hdfs.TestHFlush |
| | hadoop.hdfs.server.datanode.fsdataset.impl.TestFsDatasetImpl |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Image:yetus/hadoop:fbe3e86 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12766477/HDFS-8915.002.patch |
| JIRA Issue | HDFS-8915 |
| Optional Tests | asflicense compile javac javadoc mvninstall mvnsite
unit findbugs checkstyle |
| uname | Linux fb0640b495fb
[jira] [Commented] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
[
https://issues.apache.org/jira/browse/HDFS-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15209557#comment-15209557
]
Mingliang Liu commented on HDFS-8915:
-
Comparing with little sleep, I'm in favor of a {{GenericTestUtils.waitFor}}.
Will this patch be committed?
> 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] [Commented] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
[
https://issues.apache.org/jira/browse/HDFS-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14956472#comment-14956472
]
Vinayakumar B commented on HDFS-8915:
-
{code}Thread.sleep(10); // Lets all threads get BLOCKED{code}
This line itself was added in HDFS-9139,
Did anyone observe this test failed after HDFS-9139?
> 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] [Commented] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
[ https://issues.apache.org/jira/browse/HDFS-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14956469#comment-14956469 ] Vinayakumar B commented on HDFS-8915: - I think, this was fixed as part of HDFS-9139, I was hitting this quite often during parallel runs, just introducing little sleep, it didnt occur again. > 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] [Commented] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
[
https://issues.apache.org/jira/browse/HDFS-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14956458#comment-14956458
]
Hadoop QA commented on HDFS-8915:
-
\\
\\
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | pre-patch | 8m 54s | Pre-patch trunk has 1 extant
Findbugs (version 3.0.0) warnings. |
| {color:green}+1{color} | @author | 0m 0s | The patch does not contain any
@author tags. |
| {color:green}+1{color} | tests included | 0m 0s | The patch appears to
include 1 new or modified test files. |
| {color:green}+1{color} | javac | 8m 42s | There were no new javac warning
messages. |
| {color:green}+1{color} | release audit | 0m 22s | The applied patch does
not increase the total number of release audit warnings. |
| {color:green}+1{color} | checkstyle | 1m 32s | There were no new checkstyle
issues. |
| {color:green}+1{color} | whitespace | 0m 0s | The patch has no lines that
end in whitespace. |
| {color:green}+1{color} | install | 1m 37s | mvn install still works. |
| {color:green}+1{color} | eclipse:eclipse | 0m 36s | The patch built with
eclipse:eclipse. |
| {color:green}+1{color} | findbugs | 2m 51s | The patch does not introduce
any new Findbugs (version 3.0.0) warnings. |
| {color:green}+1{color} | native | 1m 11s | Pre-build of native portion |
| {color:red}-1{color} | hdfs tests | 54m 44s | Tests failed in hadoop-hdfs. |
| | | 80m 32s | |
\\
\\
|| Reason || Tests ||
| Failed unit tests | hadoop.hdfs.server.namenode.ha.TestStandbyCheckpoints |
| | hadoop.hdfs.server.blockmanagement.TestBlockManager |
| | hadoop.hdfs.web.TestWebHDFS |
\\
\\
|| Subsystem || Report/Notes ||
| Patch URL |
http://issues.apache.org/jira/secure/attachment/12766477/HDFS-8915.002.patch |
| Optional Tests | javac unit findbugs checkstyle |
| git revision | trunk / 2a98724 |
| Pre-patch Findbugs warnings |
https://builds.apache.org/job/PreCommit-HDFS-Build/12972/artifact/patchprocess/trunkFindbugsWarningshadoop-hdfs.html
|
| hadoop-hdfs test log |
https://builds.apache.org/job/PreCommit-HDFS-Build/12972/artifact/patchprocess/testrun_hadoop-hdfs.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HDFS-Build/12972/testReport/ |
| Java | 1.7.0_55 |
| uname | Linux asf901.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Console output |
https://builds.apache.org/job/PreCommit-HDFS-Build/12972/console |
This message was automatically generated.
> 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] [Commented] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
[
https://issues.apache.org/jira/browse/HDFS-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14768884#comment-14768884
]
Hadoop QA commented on HDFS-8915:
-
\\
\\
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | pre-patch | 11m 12s | Pre-patch trunk compilation is
healthy. |
| {color:green}+1{color} | @author | 0m 0s | The patch does not contain any
@author tags. |
| {color:green}+1{color} | tests included | 0m 0s | The patch appears to
include 1 new or modified test files. |
| {color:green}+1{color} | javac | 7m 57s | There were no new javac warning
messages. |
| {color:green}+1{color} | release audit | 0m 19s | The applied patch does
not increase the total number of release audit warnings. |
| {color:green}+1{color} | checkstyle | 1m 26s | There were no new checkstyle
issues. |
| {color:green}+1{color} | whitespace | 0m 0s | The patch has no lines that
end in whitespace. |
| {color:green}+1{color} | install | 1m 25s | mvn install still works. |
| {color:green}+1{color} | eclipse:eclipse | 0m 31s | The patch built with
eclipse:eclipse. |
| {color:green}+1{color} | findbugs | 2m 25s | The patch does not introduce
any new Findbugs (version 3.0.0) warnings. |
| {color:green}+1{color} | native | 1m 15s | Pre-build of native portion |
| {color:red}-1{color} | hdfs tests | 162m 39s | Tests failed in hadoop-hdfs. |
| | | 189m 13s | |
\\
\\
|| Reason || Tests ||
| Failed unit tests |
hadoop.hdfs.server.datanode.TestNNHandlesCombinedBlockReport |
| | hadoop.hdfs.web.TestWebHDFSOAuth2 |
\\
\\
|| Subsystem || Report/Notes ||
| Patch URL |
http://issues.apache.org/jira/secure/attachment/12756203/HDFS-8915.001.patch |
| Optional Tests | javac unit findbugs checkstyle |
| git revision | trunk / bf2f2b4 |
| hadoop-hdfs test log |
https://builds.apache.org/job/PreCommit-HDFS-Build/12474/artifact/patchprocess/testrun_hadoop-hdfs.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HDFS-Build/12474/testReport/ |
| Java | 1.7.0_55 |
| uname | Linux asf906.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Console output |
https://builds.apache.org/job/PreCommit-HDFS-Build/12474/console |
This message was automatically generated.
> 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] [Commented] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
[ https://issues.apache.org/jira/browse/HDFS-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14790739#comment-14790739 ] Anu Engineer commented on HDFS-8915: +1 (Non-Binding) [~iwasakims] Thanks for fixing this. With this change I presume that test passes consistently on your local machine. We have not seen this fail in Apache machines yet, but it is a good to have fix. Test failures does not seem to be related to this 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 > > > 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] [Commented] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
[
https://issues.apache.org/jira/browse/HDFS-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 environment.
> 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] [Commented] (HDFS-8915) TestFSNamesystem.testFSLockGetWaiterCount fails intermittently in jenkins
[ https://issues.apache.org/jira/browse/HDFS-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14711680#comment-14711680 ] Anu Engineer commented on HDFS-8915: This was a tracking bug to see if this failure happens in the apache tree. Since the only failure was reported when we had a VM outage, resolving this issue as won't fix. This test has been running without any issues for a week. 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)
