[
https://issues.apache.org/jira/browse/BROOKLYN-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15670495#comment-15670495
]
ASF GitHub Bot commented on BROOKLYN-325:
-----------------------------------------
Github user aledsage commented on a diff in the pull request:
https://github.com/apache/brooklyn-server/pull/435#discussion_r88242774
--- Diff:
core/src/main/java/org/apache/brooklyn/core/mgmt/rebind/BasicEntityRebindSupport.java
---
@@ -245,14 +249,52 @@ protected void instanceRebind(AbstractBrooklynObject
instance) {
Preconditions.checkState(instance == entity, "Expected %s and %s
to match, but different objects", instance, entity);
Lifecycle expectedState =
ServiceStateLogic.getExpectedState(entity);
if (expectedState == Lifecycle.STARTING || expectedState ==
Lifecycle.STOPPING) {
- LOG.warn("Entity {} goes on-fire because it was in state {} on
rebind", entity, expectedState);
- LOG.warn("not-up-indicators={}",
entity.getAttribute(Attributes.SERVICE_NOT_UP_INDICATORS));
- ServiceStateLogic.setExpectedState(entity, Lifecycle.ON_FIRE);
+ // If we were previously "starting" or "stopping", then those
tasks will have been
+ // aborted. We don't want to continue showing that state (e.g.
the web-console would
+ // then show the it as in-progress with the "spinning" icon).
+ // Therefore we set the entity as on-fire, and add the
indicator that says why.
+ markTransitioningEntityOnFireOnRebind((EntityInternal) entity,
expectedState);
+ }
+
+ // Clear the provisioning/termination task-state; the task will
have been aborted, so wrong to keep this state.
+
((EntityInternal)entity).sensors().remove(AttributesInternal.INTERNAL_PROVISIONING_TASK_STATE);
+
((EntityInternal)entity).sensors().remove(AttributesInternal.INTERNAL_TERMINATION_TASK_STATE);
+
+ super.instanceRebind(instance);
+ }
+
+ protected void markTransitioningEntityOnFireOnRebind(EntityInternal
entity, Lifecycle expectedState) {
+ LOG.warn("Entity {} being marked as on-fire because it was in
state {} on rebind; indicators={}", new Object[] {entity, expectedState,
entity.getAttribute(Attributes.SERVICE_NOT_UP_INDICATORS)});
+ ServiceStateLogic.setExpectedState(entity, Lifecycle.ON_FIRE);
+ ServiceStateLogic.ServiceNotUpLogic.updateNotUpIndicator(
--- End diff --
Good question. No, start/restart won't clear that not-up-indicator.
In `brooklyn-jsgui` (i.e. the web-console) there is a "reset problems"
button in the advanced tab. This makes a couple of API calls for the entity. It
sets `service.notUp.indicators` and `service.problems` to be empty maps.
I think that is probably the only way to do this currently!
We need to at least update the docs about this. What would be a better way?
Should start() and restart() effectors clear all not-up-indicators? That feels
fiddly - it might cause the entity to immediately report `serviceUp=true`
(which is why `SoftwareProcessImpl.initEnrichers()` calls
`ServiceNotUpLogic.updateNotUpIndicator(this, SERVICE_PROCESS_IS_RUNNING, "No
information yet on whether this service is running")`).
Thoughts?
> Restarting Brooklyn while entity deploying: entity shown as deploying
> indefinitely
> ----------------------------------------------------------------------------------
>
> Key: BROOKLYN-325
> URL: https://issues.apache.org/jira/browse/BROOKLYN-325
> Project: Brooklyn
> Issue Type: Bug
> Affects Versions: 0.9.0
> Reporter: Aled Sage
>
> When the Brooklyn server restarts while an entity is halfway through starting
> or stopping, on rebind that entity continues to report its sensor as
> starting/stopping. However, the task does not resume so it stays in this
> state indefinitely.
> To reproduce, run Brooklyn with persistence enabled, and try deploying a
> blueprint like that below:
> {noformat}
> location: localhost
> services:
> - type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess
> brooklyn.config:
> launch.command: sleep 20
> stop.command: sleep 20
> checkRunning.command: true
> {noformat}
> While the app is starting, terminate the Brooklyn server and then restart it.
> In the UI, the spinning icon shows that the app is still deploying. The
> entity has the following sensor values:
> {noformat}
> service.isUp: false
> service.notUp.indicators: {"service.process.isRunning":"No information on
> whether this service is running"}
> service.state: STARTING
> service.state.expected: starting @ 1470658910966 / Mon Aug 08 13:21:50 BST
> 2016
> {noformat}
> Alternatively, deploy the app normally and then invoke stop. While the app is
> stopping, terminate the Brooklyn server and then restart it. The entity has
> the following sensor values:
> {noformat}
> service.process.isRunning: false
> service.state: STOPPING
> service.state.expected: stopping @ 1470658816662 / Mon Aug 08 13:20:16 BST
> 2016
> {noformat}
> Given that the task won't resume, I'd expect the entity to be marked as
> having some kind of error. For example, the service.state as on-fire (but
> ideally without losing the fact that it was previously stopping).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
