In Alibaba Cloud Message Service specifications, each message has a default visibility timeout. After a worker receives a message, the timeout time starts.If the worker does not complete message processing within the timeout time, the message may be received and processed by another worker.
Advantage of the timeout: DeleteMessage must be displayed after message processing completes. If a worker process is crashed, the message can be processed by another worker.
Some users set the default VisibilityTimeout of a queue to a long period to ensure that the message is not released due to timeout before the worker completes message processing.
Suppose that in some application scenarios, the VisibilityTimeout of a queue is set to six hours.
A worker receives a message M1. However, the worker process is crashed or the system restarts after the worker completes message processing.
The message M1 can only be received and processed by another worker in at least six hours. In this case, it will be too complex to write programs to handle failover.
In some scenarios where the real-time requirement is high and each message needs to be rapidly responded to, it is expected that:
The VisibilityTimeout of a queue is short, for example, five minutes, so that the incomplete message can be received and processed by another worker in most five minutes after the current worker is crashed.
Message processing may cost more than five minutes, which cannot be timed out.
For such scenarios, a best practice with C# demo is provided (refer to the attachment).When a worker is processing a message, it regularly checks whether ChangeVisibility is required for the message. The work actively deletes the message after it completes processing.
If you have any question, you can post it in the forum, or join the TradeManager group of official Message Service technical support (group ID: 51222373).
1. Before running the program, set the accessId, accessKey, and endPoint.
2. Variable description:
- MessageMinimalLife indicates the minimum Life length required when a message is registered. If the remaining timeout time is only 0.1 second when a message is registered, ChangeVisibility cannot be run to extend the message life. Therefore, MessageMinimalLife ensures that the message sustains until ChangeVisibility is run. You can set this variable according to your service pressure.
- TimerInterval indicates the interval of the timer in the Manager. You only need to ensure that the timer is enabled before the message reaches MessageMinimalLife. You can set this variable to a short period (which requires frequent check).
- QueueMessageVisibilityTimeout indicates the default timeout time of the message in the Sample, which is the attribute of the queue. Each time the Sample performs ChangeVisibility, it sets the value of VisibilityTimeout to that of QueueMessageVisibilityTimeout. Therefore, the value of QueueMessageVisibilityTimeout must be greater than that of TimerInterval+MessageMinimalLife to ensure that the message is not timed out.
- MessageTimeout indicates the timeout time of the message in the Manager. If a worker is stuck, message processing is not complete in five hours (it is assumed that this duration is far beyond the normal message processing duration). The Manager does not perform ChangeVisibility for the message, but enables message visibility timeout.
3. Process description
After receiving a message, the worker registers the message, processes the message, and calls DeleteMessage of the Manager.
After a message is registered to the Manager for the first time, the Manager calls ThreadPool to schedule a ChangeVisibilityTask to check whether ChangeVisibility is required, and then adds the message to the internal message list.
The timer in the Manager regularly calls Parallel to start ChangeVisibilityTask to check all messages in the message list.
The process related to “Manager.ChangeMessageVisibility (ChangeVisibilityTask)” is displayed in the following flowchart.
Download the sample code: ChangeMessageVisibilitySample