Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BROOKLYN-325 Rebind entity starting #356

Merged
merged 8 commits into from
Sep 30, 2016

Conversation

ivanayov
Copy link
Contributor

@ivanayov ivanayov commented Sep 28, 2016

This fixes BROOKLYN-325 - when server restarts while entity is starting or stopping, on rebind it will now go on fire instead of reporting the entity's sensors as starting/stopping.

//FIXME does not set on fire root application
if (expectedState.getState() == Lifecycle.STARTING || expectedState.getState() == Lifecycle.STOPPING) {
setAttribute(SERVICE_STATE_EXPECTED, new Lifecycle.Transition(Lifecycle.ON_FIRE, new Date()));
setAttribute(SERVICE_STATE_ACTUAL, Lifecycle.ON_FIRE);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use ServiceStateLogic.setExpectedState instead of setting the two attributes yourself.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fixed in a separate commit, so the comment will not show as outdated.

LOG.warn("On rebind of {}, not calling software process rebind hooks because expected state is {}", this, expectedState);
return;
}

Lifecycle actualState = getAttribute(SERVICE_STATE_ACTUAL);
if (actualState == null || actualState != Lifecycle.RUNNING) {
if (expectedState.getState() == Lifecycle.STARTING || expectedState.getState() == Lifecycle.STOPPING) {
setAttribute(SERVICE_STATE_ACTUAL, Lifecycle.ON_FIRE);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about this one, wonder what conditions would cause it (excluding setting it on fire from above). The message below won't be correct any more if you change the state, can you update it (or log a separate msg for this case).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fixed in a separate commit, so the comment will not show as outdated.

return expected.getState();
}

public static void setActualState(Entity entity, Lifecycle state) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's delete setActualState: it's not used. The pattern used is to set the expected state, and then for the actual state to be inferred by an enricher.

oldEntities.remove(entity.getId());
}

if (ServiceStateLogic.getExpectedState(entity) == Lifecycle.STARTING || ServiceStateLogic.getExpectedState(entity) == Lifecycle.STOPPING) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this call needs to be guarded so it's not called by a HOT_STANDBY Brooklyn server (i.e. a read-only view) etc. We only want to set this if this entity is in BrooklynObjectManagementMode.MANAGED_PRIMARY.

(Note that is not the oldMode; it is the new mode that we care about).

I therefore wonder if there is a better place for this code. I'll dig around and see.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See ivanayov#5 for an alternative (and for additional tests, including for hotStandby).

@ivanayov ivanayov changed the title BROOKLYN-325 Rebind entity starting (initial PR) BROOKLYN-325 Rebind entity starting Sep 29, 2016
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 "+entity);
LOG.warn("Entity {} goes on-fire because it was in state {} on rebind",
entity, ServiceStateLogic.getExpectedState(entity));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just use expectedState rather than calling ServiceStateLogic.getExecptedState(entity) again.

Copy link
Contributor Author

@ivanayov ivanayov Sep 30, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aledsage For some reason this is not showing outdated.

ServiceStateLogic.setExpectedState(entity, Lifecycle.ON_FIRE);

if (!(entity instanceof BasicApplication) && entity.getLocations().isEmpty()) {
LOG.warn("Rebind happened during provisioning for entity {} with parent {}" +
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately this is too general. There are some entity types that will not necessarily have locations (e.g. that are not software processes, but instead bind to an API etc. For example, the GistGenerator docs example in http://docs.cloudsoft.io/blueprints/java/defining-and-deploying.html.

Let's take this out, and come back to it in a separate PR.

@aledsage
Copy link
Contributor

@iyovcheva I've added a couple more minor comments. Can you please address those, and then I think this is good to merge!

@aledsage
Copy link
Contributor

@neykov any comments you have are much appreciated as well.

@aledsage
Copy link
Contributor

Thanks @iyovcheva - LGTM; merging. We can look at the other TODOs in SoftwareProcessRebindNotRunningEntityTest.java (which were removed in the final commit?!).

@asfgit asfgit merged commit 9b88108 into apache:master Sep 30, 2016
asfgit pushed a commit that referenced this pull request Sep 30, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants