phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cody Marcel (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-1963) Irregular failures in ResultTest#testMonitorResult
Date Wed, 13 May 2015 22:50:59 GMT

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

Cody Marcel commented on PHOENIX-1963:
--------------------------------------

[~jamestaylor] Any idea why this patch isn't being picked up by hadoopqa? Unrelated, unit
test are also hanging locally, but I don't want to check this in without a passing build.

> Irregular failures in ResultTest#testMonitorResult
> --------------------------------------------------
>
>                 Key: PHOENIX-1963
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-1963
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.4.0
>            Reporter: Gabriel Reid
>            Assignee: Cody Marcel
>         Attachments: PHOENIX-1963.patch
>
>
> While validating the 4.4.0 release candidates, I had to run the phoenix-pherf test cases
a number of times to get them to pass.
> The offending test was ResultTest#testMonitorResult. I was running the test via {{maven
clean install}}, and getting results such as the following:
> {code}
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 6.034 sec <<<
FAILURE! - in org.apache.phoenix.pherf.ResultTest
> testMonitorResult(org.apache.phoenix.pherf.ResultTest) Time elapsed: 4.363 sec <<<
FAILURE!
> java.lang.AssertionError: Failed to get correct amount of CSV records. expected:<243>
but was:<261>
> 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.phoenix.pherf.ResultTest.testMonitorResult(ResultTest.java:99)
> {code}
> An important thing to point out is that I was encountering this issue on a single-CPU
virtual machine, so if there are some sensitive timing issues then they might be tickled by
my setup.
> A quick look at the code doesn't show any directly obvious causes for this, but I did
notice in the MonitorManager class that the resultHandler instance variable is protected via
itself as a monitor in the run method, and protected by the this monitor in the readResults
method. I'm not sure if this has anything to do with the underlying issue, but it does seem
a bit questionable (i.e. different monitors are being used to lock access to a single variable).



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

Mime
View raw message