Calling cancelCurrentExecution followed by startExecution leads to Exception

[kwin]

It seems that CloudManagerApi.cancelCurrentExecution() is asynchronously performed on the backend because even if that request succeeds a call to CloudManagerApi.startExection() with the same program and pipeline id directly afterwards fails with the following exception:

io.adobe.cloudmanager.CloudManagerApiException: Cannot create execution. Pipeline already running.
	at io.adobe.cloudmanager.impl.CloudManagerApiImpl.startExecution(CloudManagerApiImpl.java:151)
	at io.adobe.cloudmanager.impl.CloudManagerApiImpl.startExecution(CloudManagerApiImpl.java:140)

In the best case cancelCurrentExecution should be blocking, in the worst case it should be mentioned explicitly in the javadoc that this operation is performed asynchronously and there should be a poll mechanism being offered to wait for it to succeed.

[bstopp]

This API is blocking - the call to the AIO Endpoint is not made asynchronously.

The response being returned is from the API itself, so the Cancel request has been successfully submitted. I presume that the submission of the cancel is not the same thing as the pipeline stopping and blocking for that is not part of the API spec.

IMO The cancel.. methods in the API that handle the calls to the AIO endpoint should not block.

Adding convenience methods to block if desired until the pipeline has successfully stopped has other considerations that have no good solution:

• How is the wait accomplished? Infinite loop w/ thread sleep? Timeout?
• How long is the wait before terminating with a failure?

Because the only way to block is to: request the cancel, then wait and continuously poll the API for "Is that pipeline still executing?"

Creating this logic in the library would put an explicit implementation constraint on the caller which may limit it's ability to be consumed in different contexts. All of which enforces our assumptions and business rules on the library consumers.

[kwin]

Understood, then at least the Javadoc for cancel should be extended, to make it clear that at the point when the response has been received the cancel has not necessarily been executed yet.

[bstopp]

I will likely go back and update all of the JavaDocs to reference the respective underlying AIO API on the Cloud Manager documentation, so that there's a direct relationship between them.

I'll use this as a note to also add comments on those that are non-blocking but not necessarily complete at the time of the response.