Ошибка ScriptHost произошла, несмотря на перехват исключения - PullRequest
0 голосов
/ 29 апреля 2018

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

Я полагаю, это вызвано тем, что я использую привязку таблицы, которая находится на границе между хостом и моим кодом. Я прав? Должен ли я использовать клиент таблицы в моем коде вместо привязки? Есть ли другой подход?

Пример кода для генерации этой ситуации:

    [FunctionName("MyFunction")]
    public static async Task Run([QueueTrigger("myqueue", Connection = "Conn")]string msg, [Table("mytable", Connection = "Conn")] IAsyncCollector<DataEntity> dataEntity, TraceWriter log)
    {
        try
        {
            await dataEntity.AddAsync(new DataEntity()
            {
                PartitionKey = "1",
                RowKey = "1",
                Data = msg
            });
            await dataEntity.FlushAsync();
        }
        catch (StorageException e)
        {
           // when it is an exception that informs "entity already exists" skip it
        } 
    }

1 Ответ

0 голосов
/ 30 апреля 2018

Если функция триггера очереди не работает, Функции Azure повторяют функцию до пяти раз для данного сообщения очереди, включая первую попытку.

Если все пять попыток не удаются, среда выполнения функций добавляет сообщение в очередь с именем <originalqueuename>-poison.

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

Файл host.json содержит настройки, управляющие поведением триггера очереди:

{
    "queues": {
      "maxPollingInterval": 2000,
      "visibilityTimeout" : "00:00:30",
      "batchSize": 16,
      "maxDequeueCount": 1,
      "newBatchThreshold": 8
    }
}

Примечание : maxDequeueCount по умолчанию 5 . Число попыток обработки сообщения перед его перемещением в очередь отравления. Для ваших нужд вы можете установить "maxDequeueCount":1.

Также эти настройки относятся к общему хосту и применяются ко всем функциям. Вы не можете контролировать их для каждой функции в настоящее время.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...