GitHub user aledsage opened a pull request:
https://github.com/apache/brooklyn-server/pull/166
Minor tidy to LoopOverGroupMembersTestCase
These minor changes were motivated by a jenkins test failure, when building
an unrelated PR branch
(https://builds.apache.org/job/brooklyn-server-pull-requests/org.apache.brooklyn$brooklyn-test-framework/463/testReport/junit/org.apache.brooklyn.test.framework/LoopOverGroupMembersTestCaseTest/testMultipleChildrenOneOfWhichFails/).
They will not actually fix the problem!
```
2016-05-28 00:12:23,277 INFO TESTNG INVOKING CONFIGURATION: "Surefire
test" - @BeforeMethod
org.apache.brooklyn.test.framework.LoopOverGroupMembersTestCaseTest.setup()
2016-05-28 00:12:23,444 INFO TESTNG PASSED CONFIGURATION: "Surefire test"
- @BeforeMethod
org.apache.brooklyn.test.framework.LoopOverGroupMembersTestCaseTest.setup()
finished in 167 ms
2016-05-28 00:12:23,445 INFO TESTNG INVOKING: "Surefire test" -
org.apache.brooklyn.test.framework.LoopOverGroupMembersTestCaseTest.testMultipleChildrenOneOfWhichFails()
2016-05-28 00:12:23,922 INFO No Camp-YAML parser registered for parsing
catalog item DSL; skipping DSL-parsing
2016-05-28 00:12:24,338 WARN Service is not up when setting running on
TestSensorImpl{id=ysDIWYSf}; delayed 206ms but Sensor: service.isUp
(java.lang.Boolean) did not recover from null; not-up-indicators=null
2016-05-28 00:12:24,339 WARN Setting TestSensorImpl{id=ysDIWYSf} on-fire
due to problems when expected running, up=null, not-up-indicators: null
2016-05-28 00:12:24,340 WARN Setting TestSensorImpl{id=ysDIWYSf} on-fire
due to problems when expected running, up=null, not-up-indicators: null
2016-05-28 00:12:25,377 INFO succeedsEventually exceeded max attempts or
timeout - 11 attempts lasting 1001 ms, for
RunnableAdapter(org.apache.brooklyn.test.framework.TestFrameworkAssertions$3@6415f669)
2016-05-28 00:12:25,378 INFO failed succeeds-eventually, 11 attempts,
1002ms elapsed (rethrowing): java.lang.AssertionError: string-sensor equals
Hello World!
2016-05-28 00:12:25,603 WARN Service is not up when setting running on
Application[qSsBmD2H]; delayed 210ms but Sensor: service.isUp
(java.lang.Boolean) did not recover from false;
not-up-indicators={service-lifecycle-indicators-from-children-and-members=LoopOverGroupMembersTestCaseImpl{id=CN3zHY1A}
is not up}
2016-05-28 00:12:25,604 WARN Setting Application[qSsBmD2H] on-fire due to
problems when expected running, up=false, problems:
{service-lifecycle-indicators-from-children-and-members=Required entity not
healthy: LoopOverGroupMembersTestCaseImpl{id=CN3zHY1A}}
2016-05-28 00:12:25,605 WARN Setting Application[qSsBmD2H] on-fire due to
problems when expected running, up=false, problems:
{service-lifecycle-indicators-from-children-and-members=Required entity not
healthy: LoopOverGroupMembersTestCaseImpl{id=CN3zHY1A}}
2016-05-28 00:12:25,815 WARN Service is not up when setting running on
Application[qSsBmD2H]; delayed 209ms but Sensor: service.isUp
(java.lang.Boolean) did not recover from false;
not-up-indicators={service-lifecycle-indicators-from-children-and-members=LoopOverGroupMembersTestCaseImpl{id=CN3zHY1A}
is not up}
2016-05-28 00:12:25,840 INFO TESTNG FAILED: "Surefire test" -
org.apache.brooklyn.test.framework.LoopOverGroupMembersTestCaseTest.testMultipleChildrenOneOfWhichFails()
finished in 2394 ms
java.lang.AssertionError:
Expecting actual not to be null
at
org.apache.brooklyn.test.framework.LoopOverGroupMembersTestCaseTest.testMultipleChildrenOneOfWhichFails(LoopOverGroupMembersTestCaseTest.java:174)
```
The failing assertion at line 174 was the line below (i.e. that one of the
child test-cases does have serviceUp=true).
```
assertThat(loopChildEntity.sensors().get(SERVICE_UP)).isTrue();
```
Reviewing the code, I don't see anything wrong :-(
My suspicion is that the `AbstractEntity.initEnrichers()` are causing us
problems: it might have determined that the service is not yet up, and set it
to null - only to then have the value set back to true immediately after. It
could be that if we changed the assertion to "eventually" then it would work.
But that is pure speculation. It never fails for me locally (out of a few
hundred runs).
```
enrichers().add(ServiceNotUpLogic.newEnricherForServiceUpIfNotUpIndicatorsEmpty());
enrichers().add(ServiceStateLogic.newEnricherForServiceStateFromProblemsAndUp());
```
I also wondered about the try-catch around the call to `child.start()`,
within the loop. There is some surprising stuff that can happen when executing
tasks, when a sub-task fails. In some situations, it can cause all remaining
queued tasks to be abandoned. (Each effector is a task). However, I'd expect
that to be much more deterministic so my gut feel is that is not the problem
here.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/aledsage/brooklyn-server
fix/LoopOverGroupMembersTestCaseTest
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/brooklyn-server/pull/166.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #166
----
commit 22d9131dbc43158c19084457d26265ae42597765
Author: Aled Sage <[email protected]>
Date: 2016-05-28T14:01:29Z
Minor tidy to LoopOverGroupMembersTestCase
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
