brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ahgittin <...@git.apache.org>
Subject [GitHub] incubator-brooklyn pull request: Sensors chained for service up
Date Fri, 29 Aug 2014 22:34:04 GMT
Github user ahgittin commented on a diff in the pull request:

    https://github.com/apache/incubator-brooklyn/pull/131#discussion_r16924107
  
    --- Diff: core/src/main/java/brooklyn/entity/basic/AbstractApplication.java ---
    @@ -123,23 +137,29 @@ public AbstractApplication setParent(Entity parent) {
         public void start(Collection<? extends Location> locations) {
             this.addLocations(locations);
             Collection<? extends Location> locationsToUse = getLocations();
    -        setAttribute(Attributes.SERVICE_STATE, Lifecycle.STARTING);
    +        ServiceProblemsLogic.clearProblemsIndicator(this, START);
    +        ServiceStateLogic.setExpectedState(this, Lifecycle.STARTING);
    +        ServiceStateLogic.ServiceNotUpLogic.updateNotUpIndicator(this, Attributes.SERVICE_STATE_ACTUAL,
"Application starting");
             recordApplicationEvent(Lifecycle.STARTING);
             try {
                 preStart(locationsToUse);
    +            // if there are other items which should block service_up, they should be
done in preStart
    +            ServiceStateLogic.ServiceNotUpLogic.clearNotUpIndicator(this, Attributes.SERVICE_STATE_ACTUAL);
    +            
                 doStart(locationsToUse);
                 postStart(locationsToUse);
             } catch (Exception e) {
    -            setAttribute(Attributes.SERVICE_STATE, Lifecycle.ON_FIRE);
    +            // TODO should probably remember these problems then clear?  if so, do it
here ... or on all effectors?
    +//            ServiceProblemsLogic.updateProblemsIndicator(this, START, e);
    +            
                 recordApplicationEvent(Lifecycle.ON_FIRE);
    --- End diff --
    
    we don't currently -- this assumes that a failure during start does not necessarily mean
the application isn't running.  it's marked TODO while we better figure out the right logic.
    
    in concrete terms most failures are if a child fails to start.  the child is then on fire
and so is the app.  if restarting the child fixes it then the app will also, correctly, be
fixed.  however if the app has some other startup problem (eg locally) then it might not report
the problem and incorrectly advertise health.
    
    let's continue to think on this, not try to solve all such issues in this PR


---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message