Repeatedly attempt to run a connected component until it succeeds or a maximum number of attempts is reached. This component is used like an Iterator component, where it is attached to an existing component.
During the wait time between retries, nothing is shown in the task panel, and it may appear that although the job run hasn't completed yet, it isn't working on anything either. Once the current wait time is reached, the task will be re-added to the run for its next attempt and the job will continue.
Note: Take care when using the Retry component inside a transaction block (between the Begin and Commit components). If an error occurs on the machine or platform Matillion is running on, retrying will also fail because the transaction has not yet been rolled back. It is more sensible to attach the Retry component to a Run Orchestration component where that job contains its own transaction logic.
|Name||Text||The descriptive name for the component.|
|Number of Retries||Integer||The maximum number of attempts to retry the connected component. The total number of times the attached component could be run is one more than the number of retries - the original attempt is not a retry. After all retries have been attempted, if the last run is still a failure, the failure link is followed. The first time the component succeeds, the success link is followed.|
Certain kinds of transient failures may benefit from a delay before
retrying. The Retry Delay provides strategies for retrying quickly
or slowly, with the ability to leave longer and longer pauses between
attempts (known as backoff).
Retry immediately: the default, will immediate retry up to the maximum number of retires.
Short delay: Waits approximately 2 seconds between retries.
Short delay with backoff: Waits longer between each failure, at approximately 1, 2, 5, 10, 20, 40... seconds.
Long delay: Waits approximately 15 seconds between retries.
Long delay with backoff: Waits longer between each failure, at approximately 15, 30, 60, 120, 240... seconds.
This component makes the following values available to export into variables:
|Iterations Attempted||The number of iterations that this component attempts. This is akin to its successes plus its failures.|
|Iterations Generated||The number of iterations that have been initiated. Iterations are generated when the component runs and so this will always be the maximum requested iterations (Number of allowed retries + 1)|
|Iterations Successful||The number of iterations successfully performed. This will either be 0 or 1 since the Retry component is escaped when an iteration succeeds.|
In this example, a Webservice call is made via a Python script. If the service is temporarily unavailable or a network error occurs, this call may sometimes fail. The job canvas is shown below.
The Retry component is clipped to the Python Script component (as above) and configured as shown below. Since the failure may be caused by too many requests in a short period of time, a Retry Delay including a backoff is used to wait longer each time before retrying the request, up to 3 additional times.
Now our entire job will not fail if the Python Script call fails the first time. We get 3 more chances for success before the script fails and the job ends.