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