[
https://issues.apache.org/jira/browse/HBASE-19803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16342309#comment-16342309
]
stack commented on HBASE-19803:
-------------------------------
{quote}Maybe a possible way is to do it at once first, and then add a UT to
make sure that we always have a CategoryBasedTimeout ClassRule for every UTs.
{quote}
I endorse this approach. Our test suite becomes more and more unruly as time
goes by. Weeding and fixup consumes weeks of developer time on an ongoing
basis (witness the last few weeks of test fixup/flakie suppression). The only
counter we have to the ever-increasing disorder is enforcing more
order/constraints. Let me comment on HBASE-19873 approach over there. Great
work lads.
> False positive for the HBASE-Find-Flaky-Tests job
> -------------------------------------------------
>
> Key: HBASE-19803
> URL: https://issues.apache.org/jira/browse/HBASE-19803
> Project: HBase
> Issue Type: Sub-task
> Reporter: Duo Zhang
> Priority: Major
> Attachments: 2018-01-24T17-45-37_000-jvmRun1.dumpstream,
> HBASE-19803.master.001.patch
>
>
> It reports two hangs for TestAsyncTableGetMultiThreaded, but I checked the
> surefire output
> https://builds.apache.org/job/HBASE-Flaky-Tests/24830/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.client.TestAsyncTableGetMultiThreaded-output.txt
> This one was likely to be killed in the middle of the run within 20 seconds.
> https://builds.apache.org/job/HBASE-Flaky-Tests/24852/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.client.TestAsyncTableGetMultiThreaded-output.txt
> This one was also killed within about 1 minutes.
> The test is declared as LargeTests so the time limit should be 10 minutes. It
> seems that the jvm may crash during the mvn test run and then we will kill
> all the running tests and then we may mark some of them as hang which leads
> to the false positive.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
