Я знаю, что есть QueueTrigger материал, который вызывается, когда новое сообщение доступно в очереди. Однако эти веб-задания в «рамочном стиле» усложняют мне правильную инициализацию среды.
Вот почему я хочу сам опросить очередь, основной шаблон такой:
var account = CloudStorageAccount.Parse("connectionString");
var client = account.CreateCloudQueueClient();
// Per application initialization stuff goes here
while(true) {
var queue = client.GetQueueReference("myqueue");
var message = queue.GetMessage();
if (message != null) {
// Per message initialization stuff goes here
// Handle message
queue.DeleteMessage(message);
}
else {
Thread.Sleep(10000); // Or some exponential back-off algorithm
}
}
У меня вопрос: есть ли потенциальные проблемы с этим подходом при непрерывной работе в веб-задании? Если да, то каковы возможные альтернативы, чтобы избежать веб-заданий в стиле фреймворка?
Изменить
По просьбе Виктора, вот еще немного информации о том, почему я не хочу использовать подход QueueTrigger. Основных причин две.
Первый уже упоминался выше, это тот факт, что фреймворк вызывает метод с атрибутом QueueTrigger. Это означает, что мне нужно поместить всю инициализацию в этот метод.
У нас есть двухэтапный контейнер IoC (для каждого приложения и для каждого запроса) в наших веб-приложениях, и я хочу, чтобы веб-задания были как можно ближе к веб-приложениям, поэтому я хотел бы использовать этот двухэтапный IoC в WebJobs тоже (IoC для каждого приложения выполняет некоторую тяжелую инициализацию, которая затем повторно используется для всех запросов). Следствием этого будет то, что я должен поместить контейнер для каждого приложения в статическую переменную или синглтон, чтобы я мог получить к нему доступ из статического метода QueueTrigger. Это дизайнерская причуда, которую я не хочу делать (ИМО, Microsoft делает это слишком много, например, Thread.CurrentCulture или HttpContext.Current - это ДЕЙСТВИТЕЛЬНО антипаттерн и ухудшает тестируемость).
Идеальный SDK WebJobs для ситуации, описанной выше, сделает инфраструктуру (таймер отката, обработка отравления и т. Д.) Доступной в качестве службы, так что основной поток управления всегда остается за приложением. Это может или не может быть возможным для всех функций SDK, я не знаю SDK достаточно хорошо, чтобы судить об этом.
Вторая причина - удобство разработчика. У нас есть распределенная команда, которая иногда работает в автономных средах. Из того, что я прочитал, здесь и здесь нет возможности запустить приложение WebJob локально с эмулятором хранилища и удалить сообщения из очереди. С подходом к самооценке, который я использую сейчас, это работает как шарм.
