Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 11 Apr 2017 15:48:41 +0000 (UTC)
From: "Eric Badger (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.13061545.1491342670000.257502.1491925721896@Atlassian.JIRA>
In-Reply-To: <JIRA.13061545.1491342670000@Atlassian.JIRA>
References: <JIRA.13061545.1491342670000@Atlassian.JIRA> <JIRA.13061545.1491342670124@jira-lw-us.apache.org>
Subject: [jira] [Commented] (HADOOP-14277) TestTrash.testTrashRestarts is
 flaky
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 11 Apr 2017 15:48:46 -0000


    [ https://issues.apache.org/jira/browse/HADOOP-14277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15964551#comment-15964551 ] 

Eric Badger commented on HADOOP-14277:
--------------------------------------

[~cheersyang], thanks for the patch! I have just a few nits.

{noformat}
+      while(aliveCounts-- > 0) {
+        Thread.sleep(100);
+        countdownEmptier.countDown();
{noformat}
We shouldn't be sleeping for this long. Especially when aliveCounts is set to 5, that's an extra 1 second that we're adding to the test that shouldn't be necessary, since we verify twice. I don't think that we should be depending on sleeps at all. Anytime we are sleeping, we could instead be using a GenericTestUtils.waitFor() or something similar with a very low interval. Basically using a polling-based approach with configurable timeouts instead of trying to guess how long we need to wait. That way we aren't sitting around doing nothing for long periods of time. 

{noformat}
+    @Override public void run() {
+      while (true) {
+        // Once counts down to 0, new another latch for next interval
+        this.intervalSignal = new CountDownLatch(interval);
{noformat}
It would be nice if we didn't have to instantiate a new CountDownLatch every time we loop. Doesn't look like you can reset the CountDownLatch, but maybe use something like a CyclicBarrier with the threads set to 1? Though I'm not sure how expensive the overhead is for a CyclicBarrier. 

> TestTrash.testTrashRestarts is flaky
> ------------------------------------
>
>                 Key: HADOOP-14277
>                 URL: https://issues.apache.org/jira/browse/HADOOP-14277
>             Project: Hadoop Common
>          Issue Type: Bug
>            Reporter: Eric Badger
>            Assignee: Weiwei Yang
>         Attachments: HADOOP-14277.001.patch, HADOOP-14277.002.patch
>
>
> {noformat}
> junit.framework.AssertionFailedError: Expected num of checkpoints is 2, but actual is 3 expected:<2> but was:<3>
> 	at junit.framework.Assert.fail(Assert.java:57)
> 	at junit.framework.Assert.failNotEquals(Assert.java:329)
> 	at junit.framework.Assert.assertEquals(Assert.java:78)
> 	at junit.framework.Assert.assertEquals(Assert.java:234)
> 	at junit.framework.TestCase.assertEquals(TestCase.java:401)
> 	at org.apache.hadoop.fs.TestTrash.verifyAuditableTrashEmptier(TestTrash.java:892)
> 	at org.apache.hadoop.fs.TestTrash.testTrashRestarts(TestTrash.java:593)
> {noformat}


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org