This topic describes how to manage the visibility timeout of messages.

Background information

MNS provides the VisibilityTimeout parameter for each message. After a worker process receives a message, MNS starts timing for the visibility timeout. If a worker process does not complete processing the message within the specified timeout period, the message may be received and processed by other worker processes.

If you specify the VisibilityTimeout parameter for a message and a worker process fails when processing the message, the message is not deleted and can be processed by other worker processes.

You can set the VisibilityTimeout parameter to a large value to ensure that a worker process has enough time to process messages.

Problem

The value of the VisibilityTimeout parameter for a queue is 6 hours.

A worker process receives a message M1. However, after the worker process processes the message, the process fails or the host is restarted.

In this case, a worker process cannot receive and process the message M1until six hours later. If you use code to solve the problem, the program becomes significantly complex.

Objective

In certain scenarios, you need to process messages in a timely manner. You want to achieve the following objectives:

  • The VisibilityTimeout parameter of a queue is set to a small value, for example, 5 minutes. If a process fails, messages that have not been processed can be received and processed by other worker processes after five minutes.

  • The message processing process may take more than five minutes. The connection must remain until a message is processed.

Solution

MNS provides the C# sample code to solve the problem. To download the sample code, click here. When a worker process processes a message, MNS regularly checks whether to use the ChangeVisibility operation. After the worker process processes the message, the deleteMessage operation is used to delete the message.

If you require further assistance, submit a ticket.

The following section describes how to use the sample code to solve the problem.

  • Configure the AccessKey ID, AccessKey secret, and endpoint before running the code.

  • Variables:

    • MessageMinimalLife indicates the minimum lifetime that is required when a message is registered. For example, if a message that is registered has only 0.1 seconds before the timeout, you do not have enough time to call the ChangeVisibility operation to extend the lifetime of the message. Therefore, MessageMinimalLife ensures that messages do not time out before you can call the ChangeVisibility operation to extend the lifetime of the messages. You can specify the MessageMinimalLife variable based on your business needs.
    • TimerInterval indicates the interval that the internal timer of the manager uses for timing. Make sure that the timer is started before the specified value of the MessageMinimalLife variable ends. You can set the interval to a small value so that messages are checked frequently.
    • QueueMessageVisibilityTimeout indicates the default timeout period of messages in a queue. When you use the sample code to call the ChangeVisibility operation, the value of the VisibilityTimeout variable of the message is set to the value that is specified for the QueueMessageVisibilityTimeout variable of the queue. You must set the QueueMessageVisibilityTimeout variable to a value that is greater than the total value of the TimerInterval and MessageMimalLife variables to ensure that messages do not time out.
    • MessageTimeout indicates the timeout period of a message in the manager. For example, a worker process fails and a message is not processed within 5 hours (assuming that 5 hours are far beyond the normal processing time). In this case, the manager no longer performs the ChangeVisibility operation for the message and lefts the message time out.
  • Procedure:

    • After receiving a message, a worker process registers the message, processes the message, and then calls the Manager.deleteMessage operation to delete the message.

    • After a message is registered, the manager calls the ThreadPool.ChangeVisibilityTask operation to check whether the ChangeVisibility operation is required, and adds the message to the internal message list.

    • The timer in the manager regularly calls the Parallel.ChangeVisibilityTask operation to check all messages in the message list.

    • For more information about the Manager.ChangeMessageVisibility (ChangeVisibilityTask) operation, see the following figure. The following figure describes the procedure of managing the visibility timeout of messages.Manage the visibility timeout of messages