3

У меня есть WebJob, который запускается, когда пользователь загружает файл в хранилище blob - он запускается сообщением о хранении очереди, которое создается после завершения загрузки.Может ли Azure WebJobs опросить очереди по требованию?

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

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

Однако, поскольку минимальный интервал опроса в очереди равен 2 секундам, время, в течение которого пользователь должен ожидать вызова двух WebJobs, обычно удваивает свое время ожидания.

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

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

Или переключитесь на очередь служебной шины, чтобы улучшить реакцию на новые сообщения?

Update

В документации об использовании двоичных объектов триггеров, он говорит:

Существует исключение для сгустков, создаваемых с помощью атрибута Blob. Когда SDK WebJobs создает новый blob, он немедленно передает новый blob на любые соответствующие функции BlobTrigger. Поэтому, если у вас есть цепочка входов и выходов blob, SDK может обрабатывать их эффективно. Но если вы хотите, чтобы низкая латентность выполняла ваши функции обработки blob для blobs, которые создаются или обновляются другими способами, мы рекомендуем использовать QueueTrigger, а не BlobTrigger.

http://azure.microsoft.com/en-gb/documentation/articles/websites-dotnet-webjobs-sdk-storage-blobs-how-to/

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

Update 2

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

ответ

2

В настоящее время 2 секунды - это минимальное время, которое потребуется SDK для опроса нового сообщения. SDK делает экспоненциальное отключение опроса, поэтому вы можете настроить MaxPollingInterval на 2 секунды. config.Queues.MaxPollingInterval = TimeSpan.FromSeconds (15);

Для получения более подробной информации см http://azure.microsoft.com/en-us/documentation/articles/websites-dotnet-webjobs-sdk-storage-queues-how-to/#config

+1

Да, я также упомянул второй минимальный интервал опроса 2 в моем вопросе. Я надеялся на что-то умнее, например, что реализовано для blobs (подробнее см. Обновление моего вопроса). –

+0

Это должно произойти и для очередей. Мы отправляем быстрые уведомления, когда SDK отправляет сообщение. –

+0

Возможно ли, что быстрое отслеживание не произойдет, если очереди вывода расположены с использованием интерфейса IBinder? –