Единственная причина, по которой экземпляр роли перезагружается (перезапускается), - это когда Run метод RoleEntryPoint завершается. Обычно это происходит, когда вы:
- Переопределено Запустите метод () и
- В вашем программном коде есть необработанное исключение, из-за которого метод Run () завершает работу
Однако ваша роль перезапустится, а скорее зависнет, когда вы включите сбор журналов IntelliTrace.
Шаблон по умолчанию для WebRole не переопределяет Метод Run () , оставляя реализацию по умолчанию, то есть «Thread.Sleep (-1);». Не существует (авто) события, которое могло бы вызвать автоматическую перезапуск роли WebRole. Если вы не сделаете что-то в своей RoleEntryPoint, это приведет к завершению метода Run. Эта автоматическая переработка происходит только с WorkerRole, в котором реализован метод Run ().
ОБНОВЛЕНИЕ 1 (согласно комментарию 1)
run-Methoded of a RoleEntryPoint faces an error
Не просто ошибка, а ошибка такого рода (то есть необработанное исключение), которая приводит к завершению метода Run ().
Более того, вы не можете просто переопределить Run () в вашем WebRole, потому что ваш потомок RoleEntryPoint живет в другом домене приложения (даже в другом процессе), чем в вашем веб-приложении (так что он не будет знать об исключениях вашего приложения). Узнайте больше о Full IIS хостинге и процессе здесь .
Итак, для веб-роли у вас есть веб-приложение с полным набором функций IIS 7.0 / 7.5, которое не знает, что этот IIS является частью развертывания Azure. Global.asax - это ваше место для управления необработанными ошибками веб-приложений в ASP.NET. Проверьте этот вопрос , ответ на который является хорошим примером для обработчика Application_Error ().
Вы можете использовать статический метод RequestRecycle типа RoleEnvironment, чтобы вручную требовать перезапуска роли в вашем методе Application_Error (). Однако не рекомендую вам делать это. Я не вижу хорошей практики перезапуска веб-сервера из-за ошибки приложения. Вы должны реализовать хорошую стратегию обработки исключений и регистрации ошибок, регулярно проверять журналы ошибок и предпринимать действия, чтобы избежать критических ошибок, которые могут потребовать перезапуска сервера.
Каково ваше первоначальное намерение? Чтобы понять, когда роль будет автоматически переработана, или смоделировать ваше приложение, чтобы автоматически перерабатывать вашу роль в случае ошибки? Если это последнее, я предлагаю вам пересмотреть свои бизнес-требования / логику.
ОБНОВЛЕНИЕ 2
Я не могу говорить из уст Нила, но «сбой экземпляра» - это все, что может привести к зависанию работающей ВМ. Экземпляр в Windows Azure - это виртуальная машина, на которой размещен код вашего приложения (для подробного объяснения размещенной службы, роли, экземпляра прочитайте в этом блоге ). Ваше приложение работает в ОС Windows Server. Это виртуальная машина. Может произойти все, что угодно - от аппаратного сбоя на хосте до общего отказа программного обеспечения / драйвера гостевой ОС. Это не обязательно быть вашим кодом. Таким образом, в случае, если что-то произойдет, что приведет к сбою одной виртуальной машины - эта проблема автоматически обрабатывается Windows Azure Fabric. Если это необходимо - ваш код автоматически развертывается на другой виртуальной машине. И это происходит автоматически. Вы ничего не делаете. Представьте, что жесткий диск сломался, или модуль памяти перегорел, или сетевой интерфейс перестает отвечать на запросы - это всего лишь несколько простых проблем, которые могут привести к сбою работающей виртуальной машины. Это ошибка экземпляра.
Ошибка в вашем коде - это то, о чем вы должны позаботиться. Все остальное - заботится о контроллере Windows Azure Fabric.
ОБНОВЛЕНИЕ 3
- Что происходит с приложением asp.net в веб-ролике, если возникает исключение, и оно не обрабатывается? Будет ли приложение просто повесить в
неопределенное состояние ("сломано"), пока я его не найду или оно будет
прекращается с помощью виртуальной машины?
Этот вопрос полностью выходит за рамки! Что происходит с приложением asp.net в учетной записи общего хостинга? Или в локальной установке IIS? Сбой приложения для пользователя, чьи действия вызвали сбой. В худшем случае перезапуск пула приложений. Я никогда не видел "зависшего" приложения asp.net. Не существует такого понятия, как «прекращено приложение asp.net» или «сломано». Если это общая ошибка, которая возникает во время запуска приложения или первого запроса - приложение никогда не будет в сети. Если это ошибка, вызванная некоторой последовательностью действий пользователя - пользователь увидит ужасное сообщение об ошибке и ничего более (если у вас нет соответствующего обработчика Application_Error () в вашем Global.asax. Я думаю, что достаточно объяснений для вопроса, который не имеет ничего общего с лазурью.
- Можете ли вы вспомнить кусок кода .NET в моем приложении, который может вызвать сбой целой веб-роли, или это невозможно с
управляемый код (кроме неизвестной ошибки в .NET)?
Ты что, шутишь? Этот код разрушит вашу веб-роль и приведет к повторному использованию:
RoleEnvironment.RequestRecycle()
Пожалуйста, примите этот вопрос, так как я не думаю, что чего-то не хватает. Плюс к этому есть ответы как минимум на 4 вопроса, добавленных к оригинальному.
FINAL
Нет такой вещи, как "убить экземпляр навсегда".