[jira] [Updated] (PHOENIX-1963) Irregular failures in ResultTest#testMonitorResult

["James Taylor (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/PHOENIX-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Taylor updated PHOENIX-1963:
----------------------------------
    Issue Type: Test  (was: Bug)

> Irregular failures in ResultTest#testMonitorResult
> --------------------------------------------------
>
>                 Key: PHOENIX-1963
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-1963
>             Project: Phoenix
>          Issue Type: Test
>    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 <<< 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)