Сообщения очереди не перемещаются в подозрительную очередь

У меня есть работа, которая импортирует файлы в систему. Каждый раз, когда файл импортируется, мы создаем большой двоичный объект в Azure и отправляем сообщение с инструкциями в очередь, чтобы данные соответственно сохранялись в SQL. Мы делаем это, используя azure-webjobs и azure-webjobssdk.

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

Program.cs

public class Program
{
    static void Main()
    {
        //Set up DI
        var module = new CustomModule();
        var kernel = new StandardKernel(module);

        //Configure JobHost
        var storageConnectionString = AppSettingsHelper.Get("StorageConnectionString");
        var config = new JobHostConfiguration(storageConnectionString) { JobActivator = new JobActivator(kernel), NameResolver = new QueueNameResolver() };
        config.Queues.MaxDequeueCount = 7;
        config.UseTimers();

        //Pass configuration to JobJost
        var host = new JobHost(config);
        host.RunAndBlock();
    }
}

Функции.cs

public class Functions
{
    private readonly IMessageProcessor _fileImportQueueProcessor;

    public Functions(IMessageProcessor fileImportQueueProcessor)
    {
        _fileImportQueueProcessor = fileImportQueueProcessor;
    }

    public async void FileImportQueue([QueueTrigger("%fileImportQueueKey%")] string item)
    {
        await _fileImportQueueProcessor.ProcessAsync(item);
    }

}

_fileImportQueueProcessor.ProcessAsync(item) выдало исключение, и количество удаленных из очереди сообщений было должным образом увеличено и повторно обработано. Однако он так и не был перемещен в очередь на яд. Я приложил скриншот очередей с числом исключений из очереди более 50.

После нескольких сбоев веб-задание застряло в состоянии ожидания перезапуска, и я не смог ни остановить, ни запустить, и в итоге я полностью его удалил. После локального запуска веб-задания я увидел, что сообщения обрабатываются (я предположил, что сообщения с числом исключений из очереди более 7 должны были быть перемещены в очередь отравлений). Любые идеи о том, почему это происходит и что можно сделать, чтобы иметь желаемое поведение.

Спасибо,

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

Число очереди-удаления из очереди более 50 Poison-Queue


person lopezbertoni    schedule 26.01.2017    source источник


Ответы (1)


Фред,

Метод FileImportQueue, являющийся async void, является источником вашей проблемы.

Обновите его, чтобы вернуть Task:

public class Functions
{
    private readonly IMessageProcessor _fileImportQueueProcessor;

    public Functions(IMessageProcessor fileImportQueueProcessor)
    {
        _fileImportQueueProcessor = fileImportQueueProcessor;
    }

    public async Task FileImportQueue([QueueTrigger("%fileImportQueueKey%")] string item)
    {
        await _fileImportQueueProcessor.ProcessAsync(item);
    }
}

Причина, по которой счетчик удаления из очереди превышает 50, заключается в том, что когда _fileImportQueueProcessor.ProcessAsync(item) выдает исключение, это приводит к сбою всего процесса. Это означает, что пакет SDK веб-заданий не может выполнить следующую задачу, которая переместит сообщение в подозрительную очередь.

Когда сообщение снова появится в очереди, SDK снова обработает его и так далее.

person Vivien Chevallier    schedule 26.01.2017
comment
Красиво, хороший улов! Спасибо, это имеет смысл, я продолжу и протестирую ваше решение, и если оно сработает, я отмечу это как ответ. - person lopezbertoni; 26.01.2017
comment
К вашему сведению - это так часто встречается как ошибка пользователя, что я собираюсь выдать ошибку индексации, чтобы поймать ее раньше. См. PR здесь. - person mathewc; 26.01.2017
comment
@mathewc Спасибо за информацию. По сути, я просто воспроизвел это в среде песочницы, и после изменения Вивьен все заработало, как и ожидалось. - person lopezbertoni; 26.01.2017