Review Mode Set 1 – QUESTION no 6

[Samli]

Hi ,

Regarding below some sources say “Update the visibility timeout for the Amazon SQS queue to 2 hours to solve this problem.” Is the right answer but you mentioned below is right answer. Can you explain why updating time to 2 hours is not right answer??

“Reconfigure the SQS redrive policy and set maxReceiveCount to 10. This will allow the consumers to retry the messages before sending them to the dead-letter queue.”

6. QUESTION

Category: CSAP – Continuous Improvement for Existing Solutions

A media company uses the AWS Cloud to process and convert its video collection. An Auto Scaling group of Amazon EC2 instances processes the videos and scales based on the number of messages in an Amazon Simple Queue Service (SQS) queue. These SQS messages contain links to the videos, each taking about 20-40 minutes to process.

The management has set a redrive policy on the SQS queue to send failed messages to a dead-letter queue. The visibility timeout has been set to 1 hour, and the maxReceiveCount has been set to 1. When there are messages on the dead-letter queue, an Amazon CloudWatch alarm has been set up to notify the development team.

Within a few days of operation, the dead-letter queue received several videos that failed to process. The developers did not find any operational errors in the application logs and confirmed that no videos exceeded the expected processing time. Upon examining the CloudTrail logs, the team noted that the application was making repeated ReceiveMessage API calls in quick succession for specific videos, indicating retry attempts.

Which of the following options should the solutions architect implement to help solve the above problem?

<ul type=”disc”>

[Samli]

anu update?

[Samli]

Any update on this please.

[Neil-TutorialsDojo]

Hello Samli,

Good Day!

Let’s review the scenario. The visibility timeout is set to 1 hour, which means if a message takes longer than 1 hour to process, it will reappear in the queue. Given that the processing time is only 20-40 minutes, a 1-hour visibility timeout is more than sufficient. The dead-letter queue received several videos that failed to process, but there were no operational errors and no videos exceeded the expected processing time as mentioned in the scenario. This suggests that the problem lies not with the processing time but with the retry attempts. It could also means that other situations cause errors to not show up in the application logs like transient network issues. The scenario also indicates repeated ReceiveMessage API calls for specific videos, pointing to retry attempts as the issue. Which also relates to the maxReceiveCount that was set to 1, meaning that if a message fails to process on its first attempt, it is sent to the dead-letter queue.
Extending the visibility timeout to 2 hours could prevent messages from being prematurely retried before processing, but it doesn’t address the core issue related to retry attempts and the current visibility timeout should already provide sufficient time for the messages to be processed without becoming visible again for reprocessing. Therefore, increasing the maxReceiveCount to 10 would allow the system to retry processing the message multiple times before sending it to the dead-letter queue. This change would handle transient issues or temporary delays more effectively without altering the visibility timeout.

I hope this clarifies your question. If you need any further clarification, please let us know.

Regards,
Neil @ Tutorials Dojo