2014-02-05 2 views
0

Я создал простой Azure WebJob, который использует триггер QueueInput. Он был развернут без каких-либо проблем, и я планирую его через портал управления так, чтобы он «постоянно работал»WebJob не запускает

Первоначальное тестирование показалось прекрасным, после того, как задание было запущено вскоре после размещения чего-либо в очереди.

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

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

Когда я вошел в портал управления, на этот раз я заметил, что работа была отмечена как «Прервана» на странице WebJobs. Это было похоже на то, что только за 10 секунд до того, как статус изменился на «Бег». И тогда работа сразу же вызвала то, что было помещено в очередь за ночь до этого, как и ожидалось.

Поскольку это альфа-релиз, я ожидаю сбоев. Просто интересно, есть ли у кого-то другой подобный опыт.

+0

Не могли бы вы предоставить код своей работы? –

+0

Кроме того, вы используете бесплатный уровень для веб-сайтов или какой? –

+0

WebSite работает в режиме общего доступа, а не в свободном доступе. – iturner100

ответ

2

Для SDK WebJobs ваша работа должна выполняться для прослушивания триггеров (новые сообщения очереди, новые капли и т. Д.). На сайтах Azure для бесплатных уровней есть квоты, и ваша работа будет спать, а это значит, что больше не слушайте триггеры. Использование сайта может привести к его оживанию и снова начать прослушивание триггеров.

На панели инструментов SDK будет отображаться значок предупреждения рядом с функциями, если хостинг-задание не работает (он обнаруживает это с помощью битов сердца).

+0

Работа выполняется на веб-сайте, который включает в себя как mvc, так и webapi. Json отправляется на webapi, что в конечном итоге приводит к тому, что элемент помещается в очередь хранения. У webjob есть триггер очереди, который отправляется на внешний api Так что, основываясь на этом порядке событий, это предполагает, что время жизни webjob _isn't_ связано со временем жизни самого веб-сайта. В соответствии с оригинальным сообщением панель управления показывает работу как «прерванная», а затем, похоже, возвращает работу в состояние «Запуск». Одна вещь, которая может иметь значение, заключается в том, что моя работа использует метод async ... – iturner100

+0

SDK не поддерживает async. Я бы посоветовал сначала все это синхронизировать. Когда работает веб-задание (то есть код C#, относящийся к Microsoft.WindowsAzure.Jobs.JobHost), он производит сердечный ритм. Панель приборов обнаруживает, что сердцебиение определяет, неожиданно ли абонент неожиданно прервался. Панель управления будет использовать это, чтобы предупредить вас о том, что хосты не запущены. –

2

Убедитесь, что ваш сайт настроен с настройкой «Всегда включено».

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

http://azure.microsoft.com/en-us/documentation/articles/web-sites-configure/

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

Смежные вопросы