Что такое TTL для сообщения, если режим приема сообщений - это ReceiveAndDelete в служебной шине Azure?

Question

Я получаю сообщение от служебной шины в режиме ReceiveAndDelete и запускаю очень длительный вычислительный процесс, который после завершения отправляет письмо.У меня во всех моих методах регистрируется ошибка в моем методе длительного запуска.Однако метод работает в течение 10-15 минут и перестает отвечать на запросы, после чего он не регистрирует ошибку и не отправляет электронное письмо.Интересно, это может быть связано с TTL сообщения.

Посоветуйте, пожалуйста, что мне делать?

    private static async Task ProcessMessagesAsync(Message message, CancellationToken token)
    {
       try
         {

           IQueueClient queueClient = new QueueClient(serviceBusConnectionString, serviceBusQueueName, ReceiveMode.ReceiveAndDelete);


            var receivedMessageTrasactionId = Convert.ToInt64(Encoding.UTF8.GetString(message.Body));

            // Very Long Running Method  
            await DataCleanse.PerformDataCleanse(receivedMessageTrasactionId);
                         // to avoid unnecessary exceptions.
          }

        catch (Exception ex)
        {
          Log4NetErrorLogger(ex);
          throw ex;
        }
    }

Answer 1

При получении сообщения в режиме ReceiveAndDelete время жизни сообщения не имеет значения.Как только сообщение получено на стороне клиента, оно будет удалено из брокера.В случае ошибки сообщение пропало.Вот почему рекомендуется использовать режим приема PeekLock, если вы хотите иметь более безопасный механизм получения и обработки сообщений.Предупреждение о времени обработки.Я не буду вдаваться в подробности, так как информации достаточно, но вы можете либо обновить блокировку сообщения, либо обработать его, чтобы устранить необходимость в обновлении блокировки.В этом ответе .

вы найдете альтернативы.