[
https://issues.apache.org/jira/browse/PHOENIX-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14552029#comment-14552029
]
Gabriel Reid commented on PHOENIX-1963:
---------------------------------------
Relaxing the assertion sounds fine, but do we have a decent idea on why this
test is/was flapping? Any chance that this is something to worry about in terms
of correctness?
> 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-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)
