Удалить после достижения таймаута видимости, и сообщение было запрошено

Question

Предположим, у меня есть работа, которая занимает от 10 секунд до 40 секунд.
Тайм-аут видимости установлен в 30 секунд.

Задание было завершено за 40 секунд, и, таким образом, сообщение вернулось в очередь, видимое другим работникам.

Рабочий, который занял 40 секунд, удаляет сообщение.

1. Удалось ли это удалить сообщение?
2. Будет ли работа удалена из очереди?

Спасибо.

Answer 1

Если потребитель не имеет к сообщению только по истечению его Тайм-аут видимости, его удаление делает удалить его из очереди ... обычно.

DeleteMessage

Удаляет указанное сообщение из указанной очереди. Вы указываете сообщение с помощью дескриптора получения сообщения, а не MessageId, который вы получаете при отправке сообщения. Даже если сообщение заблокировано другим считывателем из-за установки таймаута видимости, оно все равно удаляется из очереди.

До сих пор, так хорошо, правда?

Но есть явные оговорки.

Примечание

Квитанция ручка связана с конкретным экземпляром приема сообщения. Если вы получаете сообщение более одного раза, то квитанция получения, которую вы получаете каждый раз, когда вы получаете сообщение, отличается. Если вы не предоставили последний обработанный квитант квитанции для сообщения при использовании действия DeleteMessage, запрос будет выполнен успешно, но сообщение не может быть удалено.

Именно поэтому она «может не» быть удалены не объясняется, но есть несколько причин, которые приходят на ум:

Может быть, что SQS не помнит бесконечный регресс на удаление ручек , Если бы потребители получили одно и то же сообщение, скажем, 576 раз, было бы разумно, что (например) 16-й последовательный обработчик удаления мог бы быть давно отброшен SQS, так как прошло столько времени ...

or , это может быть причудой распределенной архитектуры SQS. Для очередей, отличных от FIFO, дизайн службы таков, что в случае какой-либо внутренней несогласованности SQS всегда будет предпочитать, чтобы сообщение было доставлено и удалено «по крайней мере один раз», и с оперативной точки зрения 2 доставки далеко предпочитают более 0 поставок.

Подразумевается, что последний потребитель, получивший сообщение, должен удалить его, и любые попытки удалить его потребителями, которые получили его ранее и долгое время удерживали, вероятно, также удастся.

Котировки от SQS API Reference: DeleteMessage.