[
https://issues.apache.org/jira/browse/JCLOUDS-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16011869#comment-16011869
]
Ignasi Barrera commented on JCLOUDS-1298:
-----------------------------------------
Interesting. In ProfitBricks there is a similar situation, where an operation
can block a Datacenter, and any other operation that affects that datacenter is
not allowed. We have a [couple
utilities|https://github.com/jclouds/jclouds/tree/master/providers/profitbricks/src/main/java/org/jclouds/profitbricks/compute/concurrent]
to model that and all ops that can block a datacenter are executed [like
this|https://github.com/jclouds/jclouds/blob/master/providers/profitbricks/src/main/java/org/jclouds/profitbricks/compute/ProfitBricksComputeServiceAdapter.java#L212-L218].
This is only implemented in the portable abstraction and clients are free to
use that ProvisioningManager or not when directly using the provider API.
We could implement something similar to ProfitBricks by polling the
{{provisioningState}} of the objects (we already have a {{Provisionable}}
marker interface to designate such objects), or we could implement it directly
in the HTTP layer.
We could populate the headers to the returned objects, but that does not look
OK. Instead, we'd need some kind of specialization of the HTTP driver's base
class, to implement the status polling. By default, drivers do not retry on 2xx
responses, so we'll need to change that if we want to make that transparent to
the API and want to keep return objects clean without HTTP specific details
such as the response headers.
I think an approach similar to ProfitBricks could be better, as we wouldn't be
blocking on the API by default. Thoughts?
> [Azure ARM] Handle async operations
> -----------------------------------
>
> Key: JCLOUDS-1298
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1298
> Project: jclouds
> Issue Type: Improvement
> Components: jclouds-compute
> Affects Versions: 2.0.1
> Reporter: Svetoslav Neykov
> Labels: azurecompute-arm
>
> Azure's API could choose to continue an operation as async if it takes too
> long to complete. To let the client know it should continue polling for the
> result it includes the operation URL in an {{Azure-AsyncOperation}} header.
> The client is supposed to poll the operation URL (the value of the header)
> before declaring success/failure.
> With the current implementation an operation could still be in progress and
> jclouds return a success result. The {{provisioningState}} property would
> still be in an {{Updating}} state.
> Proposal:
> When the response contains the {{Azure-AsyncOperation}} header don't return
> yet, but wait for the state to transition to success/failure before giving
> control back to the caller.
> Related to https://issues.apache.org/jira/browse/JCLOUDS-1296; If operations
> block and the result is not used until success of the operation, instances of
> "409 Conflict" responses should decrease dramatically.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
