[
https://issues.apache.org/jira/browse/BROOKLYN-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15350767#comment-15350767
]
ASF GitHub Bot commented on BROOKLYN-264:
-----------------------------------------
Github user bostko commented on a diff in the pull request:
https://github.com/apache/brooklyn-server/pull/211#discussion_r68554342
--- Diff:
software/base/src/main/java/org/apache/brooklyn/entity/software/base/lifecycle/MachineLifecycleEffectorTasks.java
---
@@ -709,7 +713,24 @@ protected void doStop(ConfigBag parameters,
Callable<StopMachineDetails<Integer>
DynamicTasks.queue("pre-stop", new PreStopCustomTask());
+ // BROOKLYN-263:
+ // With this change the stop effector will always wait for
machinelocation to provision, so it can stop it.
+ // However in some situations if the stop effector is called in
less than 8 seconds after start was called,
+ // it may be safe to skip this wait and proceed with stop.
+ // Hesitant about parameterising this.
Maybe<MachineLocation> machine =
Machines.findUniqueMachineLocation(entity().getLocations());
+ /*Do not retry if non-jclouds location has started.*/
+ if
(Boolean.TRUE.equals(entity().sensors().get(Sensors.newBooleanSensor("jclouds.provisioningStarted")))
+ && machine.isAbsent()) {
+ org.jclouds.util.Predicates2.retry(new
Predicate<MachineLifecycleEffectorTasks>() {
--- End diff --
What do you think about using `Predicates2.retry` across Apache Brooklyn.
Can you suggest a guava alternative or what do you think about adding such
function in `brooklyn-core`?
> Stop app while VM still being provisioned: vm is left running when app is
> expunged
> ----------------------------------------------------------------------------------
>
> Key: BROOKLYN-264
> URL: https://issues.apache.org/jira/browse/BROOKLYN-264
> Project: Brooklyn
> Issue Type: Bug
> Affects Versions: 0.9.0
> Reporter: Aled Sage
>
> A customer deployed an app to AWS, but while the VM was still starting up
> they stopped (and thus expunged) the app. The app disappeared from the
> Brooklyn web-console, but the starting VM was left behind in AWS.
> This is simple to reproduce:
> 1. deploy a simple blueprint, such as:
> {noformat}
> location: aws-ec2:us-east-1
> services:
> - type: org.apache.brooklyn.entity.machine.MachineEntity
> {noformat}
> 2. wait for the VM to appear in the AWS web-console (with state
> "initialising")
> 3. call the {{stop}} effector on the top-level app.
> ---
> Looking at the {{start}} task that was executing at the time when {{stop}}
> was called, below is the thread's stack trace:
> {noformat}
> Provisioning machine in JcloudsLocation[AWS
> Virginia:AAAAAAAAAAAAAAAAAAAA/aws-ec2:us-east-1@eyNrLIo5]
> Task[provisioning (AWS Virginia)]@MJITkjw0
> Submitted by SoftlyPresent[value=Task[start]@tKw0qJET]
> In progress, thread waiting (notify) on
> java.util.concurrent.CountDownLatch$Sync@2ed5be36
> At:
> org.jclouds.concurrent.FutureIterables.awaitCompletion(FutureIterables.java:149)
>
> org.jclouds.compute.internal.BaseComputeService.createNodesInGroup(BaseComputeService.java:214)
>
> org.jclouds.ec2.compute.EC2ComputeService.createNodesInGroup(EC2ComputeService.java:149)
>
> org.apache.brooklyn.location.jclouds.JcloudsLocation.obtainOnce(JcloudsLocation.java:726)
>
> org.apache.brooklyn.location.jclouds.JcloudsLocation.obtain(JcloudsLocation.java:616)
>
> org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ObtainLocationTask.call(MachineLifecycleEffectorTasks.java:406)
>
> org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ObtainLocationTask.call(MachineLifecycleEffectorTasks.java:396)
>
> org.apache.brooklyn.util.core.task.Tasks.withBlockingDetails(Tasks.java:98)
>
> org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ProvisionMachineTask.call(MachineLifecycleEffectorTasks.java:380)
>
> org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ProvisionMachineTask.call(MachineLifecycleEffectorTasks.java:364)
>
> org.apache.brooklyn.util.core.task.DynamicSequentialTask$DstJob.call(DynamicSequentialTask.java:359)
>
> org.apache.brooklyn.util.core.task.BasicExecutionManager$SubmissionCallable.call(BasicExecutionManager.java:519)
> {noformat}
> From this, we can see that we are still calling jclouds. This means that
> jclouds has not yet returned to Brooklyn the VM's id. It also means that the
> {{MachineEntity}} will not have been given a {{JcloudsSshMachineLocation}}
> instance.
> When {{stop}} is called on the {{MachineEntity}}, it doesn't have a machine
> location instance so it doesn't have anything to ask to stop. This is why the
> VM is left running.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
