Auto-Retry Deployments
If a package deployment fails, you can configure the system to retry the deployments automatically. By enabling auto-retry for deployments in ThingWorx Software Content Management in ThingWorx Utilities, you allow users to create deployments that are automatically retried upon failure or time-out.
To monitor deployments and automatic retries, navigate to the View Assets for Deployments page. For each target asset, this page displays the status of a selected deployment and timestamps for the downloading and installing states. In addition, it displays the following information about auto-retries of the deployment for each target asset:
• Auto-Retries Remaining — The number of times remaining that the deployment will be retried.
• Max Number of Auto-Retries — The maximum number of auto retries to be attempted for a deployment.
How Auto-Retry Works
When a deployment fails and is auto-retried, it goes through multiple states as described in the following table:
|
State
|
Description
|
|
Pending Retry
|
The deployment is in the “pending retry” state when it waits for the server to start the retry.
|
|
Retrying
|
The “retrying” state indicates that the server is retrying the deployment.
During a successful retry, the deployment of a package goes from the “retrying” state to the “completed” state.
If there is a failed retry, the transition to another state depends on the state during which the process failed. Consider the following scenarios:
• For a file-based package, during the “notifying” state, if the edge device does not respond for a specified time period, the deployment transitions directly to the “aborted” state. If the notification fails for any other reason, the deployment transitions to the “failed” state.
• For a file-based package, during the “downloading” state, if the download times out or is interrupted by a network event and the download fails, the deployment transitions to the “failed” or “aborted” state.
|
|
Note the following points:
• If a deployment to an agent times out or is interrupted and the download has not started yet, the deployment to that agent will be started over again from the “notifying” state.
• If a deployment times out or is interrupted and the file has been partially downloaded to an agent when the deployment to that agent fails, the deployment to that agent will start from the “notifying” state. However, when the deployment enters the “downloading” state of the retry, the download resumes.
• If a deployment fails after a file has been completely downloaded or if an MD5 check fails on the downloaded file, the deployment starts over and the entire file will be downloaded again.
• If the user aborts the deployment, no retries are performed. The delivery target transitions directly to the “Canceled by User” state.
|
|
