phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajeshbabu Chintaguntla (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-1963) Irregular failures in ResultTest#testMonitorResult
Date Mon, 01 Jun 2015 18:51:18 GMT


Rajeshbabu Chintaguntla commented on PHOENIX-1963:

[] can you check whether it's committed to 4.4 branches if not please
commit. Thanks

> Irregular failures in ResultTest#testMonitorResult
> --------------------------------------------------
>                 Key: PHOENIX-1963
>                 URL:
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.4.0
>            Reporter: Gabriel Reid
>            Assignee: Cody Marcel
>             Fix For: 5.0.0, 4.4.0, 4.5.0, 4.4.1
>         Attachments: PHOENIX-1963-master.patch, PHOENIX-1963.patch, 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 <<<
> java.lang.AssertionError: Failed to get correct amount of CSV records. expected:<243>
but was:<261>
> at
> at org.junit.Assert.failNotEquals(
> at org.junit.Assert.assertEquals(
> at org.junit.Assert.assertEquals(
> at org.apache.phoenix.pherf.ResultTest.testMonitorResult(
> {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

View raw message