[
https://issues.apache.org/jira/browse/OOZIE-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Kanter updated OOZIE-1114:
---------------------------------
Description:
Some of the test classes keep a reference to the Services singleton as a class
variable and then also re-create the Services in some of its test methods.
This can cause it to not properly shut down all of the actual services, which
can is causing (at least some of) the flakey test failures because some of
those still running services interfere with some of the tests.
The typical pattern where this issue is happening looks like this:
{code}
public class TestWhatever {
private Services services1;
setup() {
services1 = new Services();
services1.init();
}
testSomething() {
Services.get().destroy(); // destroys services1's services
Services services2 = new Services(); // services1 no longer
points to the internal singleton
services2.init();
}
tearDown() {
services1.destroy(); // does not destroy the services started
by services2, but does set the internal singleton to null so we've now lost the
only remaining reference to those services
}
{code}
You can see a concrete example of this by looking at
TestStatusTransitService.testCoordStatusTransitServiceSuspendedWithError
In general, we should make sure to properly destroy the Services at the end of
each test
was:
Some of the test classes keep a reference to the Services singleton as a class
variable and then also re-create the Services in some of its test methods.
This can cause it to not properly shut down all of the actual services, which
can is causing (at least some of) the flakey test failures because some of
those still running services interfere with some of the tests.
The typical pattern where this issue is happening looks like this:
{code}
public class TestWhatever {
private Services services1;
setup() {
services1 = new Services();
services1.init();
}
testSomething() {
Services.get().destroy(); // destroys services1's services
Services services2 = new Services(); // services1 no longer
points to the internal singleton
services2.init();
}
tearDown() {
services1.destroy(); // does not destroy the services started
by services2, but does set the internal singleton to null so we've now lost the
only remaining reference to those services
}
{code}
You can see a concrete example of this by looking at
TestStatusTransitService.testCoordStatusTransitServiceSuspendedWithError
> Some tests don't use the Services singleton properly
> ----------------------------------------------------
>
> Key: OOZIE-1114
> URL: https://issues.apache.org/jira/browse/OOZIE-1114
> Project: Oozie
> Issue Type: Bug
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Fix For: trunk
>
>
> Some of the test classes keep a reference to the Services singleton as a
> class variable and then also re-create the Services in some of its test
> methods. This can cause it to not properly shut down all of the actual
> services, which can is causing (at least some of) the flakey test failures
> because some of those still running services interfere with some of the
> tests.
> The typical pattern where this issue is happening looks like this:
> {code}
> public class TestWhatever {
> private Services services1;
> setup() {
> services1 = new Services();
> services1.init();
> }
> testSomething() {
> Services.get().destroy(); // destroys services1's services
> Services services2 = new Services(); // services1 no longer
> points to the internal singleton
> services2.init();
> }
> tearDown() {
> services1.destroy(); // does not destroy the services started
> by services2, but does set the internal singleton to null so we've now lost
> the only remaining reference to those services
> }
> {code}
> You can see a concrete example of this by looking at
> TestStatusTransitService.testCoordStatusTransitServiceSuspendedWithError
> In general, we should make sure to properly destroy the Services at the end
> of each test
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
