brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From geomacy <...@git.apache.org>
Subject [GitHub] brooklyn-server issue #443: Adds maxConcurrentChildCommands parameter to Dyn...
Date Fri, 25 Nov 2016 17:45:45 GMT
Github user geomacy commented on the issue:

    https://github.com/apache/brooklyn-server/pull/443
  
    Have done some more testing with this, with the blueprint:
    ```
    name: test
    location: amazon-eu-central-1
    services:
    - type: org.apache.brooklyn.entity.group.DynamicCluster:0.10.0-SNAPSHOT
      brooklyn.config:
        dynamiccluster.firstmemberspec:
          $brooklyn:entitySpec:
            type: org.apache.brooklyn.entity.software.base.EmptySoftwareProcess
            name: first
        dynamiccluster.memberspec:
          $brooklyn:entitySpec:
            type: org.apache.brooklyn.entity.software.base.EmptySoftwareProcess
            name: VM
        cluster.initial.size: 20
        cluster.maxConcurrentChildCommands: 3
    ```
    and one issue I noticed was that, once you've deployed the cluster, if you have second
thoughts and decide to stop it when only a few nodes have started, say three, the stop effector
call "goes to the back of the queue", and the remaining seventeen nodes gradually start up,
three at a time, before the stop finally gets its chance to do anything.   Then the nodes
gradually shut down (oddly, two at a time?).
    
    I think this would be sufficiently annoying for users that we should think about allowing
priority to stop commands?
    



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