[
https://issues.apache.org/jira/browse/PHOENIX-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14552721#comment-14552721
]
Cody Marcel commented on PHOENIX-1963:
--------------------------------------
It's a sync issue between the write flush to file and the read. We only read
the result file back in for testing purposes. It's never called in a normal
workflow.
In the end this is basically a jmx metrics dump to csv at a given interval.
Worst case is a few would be missing. I believe all the intended results are
being flushed though. When I look at the file it has what is expected. I can
look into better sync on the monitor at later time though.
> 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)
