This topic describes the default retry policies and dead-letter queues for Message Integration.
Retry policies
A retry policy defines how a failed task is retried. Message Integration supports two retry policies: backoff retry and exponential decay retry.
Backoff retry (Default): Retries a failed task up to three times. The retry interval is a random value between 10 seconds and 20 seconds.
Exponential decay retry: Retries a failed task up to 176 times over a total duration of one day. The retry interval increases exponentially to a maximum of 512 seconds. The specific retry intervals are 1, 2, 4, 8, ..., 512 seconds.
Fault tolerance policies
A fault tolerance policy defines how errors are handled. Two types of fault tolerance policies are supported:
Fault tolerance allowed (Recommended): Allows exceptions to occur without blocking task execution. If the number of retries exceeds the maximum limit, the message is delivered to a dead-letter queue or discarded based on your configuration.
Fault tolerance prohibited: If an exception occurs and the number of retries exceeds the limit set in the retry policy, task execution is blocked. The task status then changes to Ready.
If an unrecoverable error occurs, such as a resource configuration error, the task status is set to Startup Failed.
Dead-letter queues
Dead-letter queues are configured on a per-task basis. If a message cannot be processed or the number of retries exceeds the maximum limit, the original raw data is sent to the dead-letter queue. This feature is disabled by default.
Currently, dead-letter messages can be sent to ApsaraMQ for RocketMQ, Simple Message Queue (formerly MNS), ApsaraMQ for Kafka, and EventBridge.