[
https://issues.apache.org/jira/browse/OOZIE-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Kanter updated OOZIE-2486:
---------------------------------
Attachment: OOZIE-2486.001.patch
These are the affected tests:
- testGetSLAEventsForCombined
- testGetSLAEventsForOR
- testGetSLAEventsForCoordActionId
- testGetSLAEventsForCoordJobId
The failures seem to be the result of HSQLDB. It’s not respecting the
{{initial-value}} of the {{@SequenceGenerator}} on the {{event_id}} in
{{JsonSLAEvent}}. We set it to 1, which is also the default value, but no
matter what I set it to, it always starts with 0 in the tests. I wasn’t able
to find anything on this in looking around the internet. I did verify that
Derby behaves correctly (so I’m assuming Postgres, MySQL, and Oracle do as
well).
The above tests are looking for the coordId1 event, which, due to HSQLDB, has
event id 0 instead of 1. The query in the tests looks for ids > 0, so if they
are the first to run, it will not include coordId1, and the test will fail.
However, {{testGetSLAEventsForCoordJobId}} does not ever fail because it’s
using -1 instead of 0 in the query.
These are flakey because the sequence generator is static and doesn’t get
reset, even if you wipe the data from the database. In other words, when we
populate the data for the next test, the event ids continue where they left off
instead of the initial value.
Given that I can’t fix HSQLDB here, I’ve modified the other test methods to
also use -1 instead of 0, and added a comment explaining why.
> TestSLAEventsGetForFilterJPAExecutor is flakey
> ----------------------------------------------
>
> Key: OOZIE-2486
> URL: https://issues.apache.org/jira/browse/OOZIE-2486
> Project: Oozie
> Issue Type: Bug
> Components: tests
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Fix For: trunk
>
> Attachments: OOZIE-2486.001.patch
>
>
> The test method that fails varies from different runs, but you'll see
> something like this:
> {noformat}
> testGetSLAEventsForOR(org.apache.oozie.executor.jpa.TestSLAEventsGetForFilterJPAExecutor)
> Time elapsed: 0.013 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<4> but was:<3>
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.failNotEquals(Assert.java:287)
> at junit.framework.Assert.assertEquals(Assert.java:67)
> at junit.framework.Assert.assertEquals(Assert.java:199)
> at junit.framework.Assert.assertEquals(Assert.java:205)
> at
> org.apache.oozie.executor.jpa.TestSLAEventsGetForFilterJPAExecutor.testGetSLAEventsForOR(TestSLAEventsGetForFilterJPAExecutor.java:127)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:24)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> You also see this if you run some of the test methods individually.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
