Push backoff policy - Simple Message Queue (formerly MNS)

This topic describes the push backoff policy of Simple Message Queue (formerly MNS).

Background information

If a subscription is unavailable, Simple Message Queue (formerly MNS) uses a push backoff algorithm to adjust the push rate and the number of messages sent to downstream subscribers to ensure service availability. The retry interval and the maximum number of messages per push are adjusted based on the number of consecutive push failures:

Retry interval: The interval gradually increases from 0 to 500 milliseconds, eventually reaching a maximum of 60 seconds.
Maximum number of messages per push: The number gradually decreases from 32 to 1.

When Simple Message Queue (formerly MNS) detects that the subscription is available again, it uses a fast recovery algorithm to restore the push speed and number of messages to their initial states within 100 seconds.

Important

During a push backoff, the message retry interval increases and may no longer match the settings specified in the retry policy (NotifyStrategy). In most cases, the number of retries for a message decreases. We recommend that you configure a dead-letter queue for the subscription in this scenario.

Reasons for subscription unavailability

When a topic pushes messages to a subscriber, the subscription may become unavailable in the following scenarios:

Queue: The queue to which the topic is subscribed does not exist. This occurs if the subscribed queue is deleted.
Important
Before you delete a queue, make sure that the queue is not subscribed to any topics that are in use to prevent business interruptions.
HTTP(S): If the number of consecutive failed attempts to push messages to an HTTP(S) subscriber is too high, Simple Message Queue (formerly MNS) considers the subscription unavailable.
Note
You must process the POST requests sent by Simple Message Queue (formerly MNS) on your HTTP(S) endpoint and return the correct HTTP status codes.
After a message is pushed to an HTTP(S) subscriber, MNS determines whether the push is successful based on the HTTP status code returned by the subscriber. If the HTTP status code is in the range of [200, 400), the push is considered successful. Any other status code indicates a push failure.

Precautions

The push backoff mechanism cannot be manually enabled or disabled.
If a subscription remains unavailable for longer than the message retention period, messages that exceed the retention period are discarded. If a dead-letter queue is configured, these messages are delivered to the dead-letter queue instead. Therefore, you must ensure subscriber availability or configure a dead-letter policy for your subscriptions.
The push backoff mechanism applies to all messages in an unavailable subscription for a specific topic.