[ 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)