[
https://issues.apache.org/jira/browse/PHOENIX-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14544637#comment-14544637
]
Hudson commented on PHOENIX-1963:
---------------------------------
SUCCESS: Integrated in Phoenix-master #753 (See
[https://builds.apache.org/job/Phoenix-master/753/])
PHOENIX-1963 - Irregular failures in ResultTest#testMonitorResult (cmarcel: rev
289a875bd1cd76b6437ae1400d6c324bfe3e0754)
* phoenix-pherf/standalone/pherf.sh
* phoenix-pherf/cluster/pherf.sh
* phoenix-pherf/src/test/java/org/apache/phoenix/pherf/ResultTest.java
* phoenix-pherf/src/main/java/org/apache/phoenix/pherf/jmx/MonitorManager.java
> 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)
