2012-01-10 8 views
6

Por lo que recuerdo, una instancia de función debería reiniciar automáticamente después de un bloqueo/falla. Para probar ese comportamiento, escribí una aplicación que aplica una excepción de falta de memoria y mi aplicación se colgó. La instancia de rol no realizó un reinicio, porque aún se estaba ejecutando y está bien, la instancia solo reinició el tiempo de ejecución de .NET.¿Después de qué tipo de excepciones/bloqueos se reinicia una instancia de Azure Cloud?

Estoy tratando de averiguar cómo una instancia reacciona a diferentes errores. En mi caso, un reinicio no fue necesario. ¿Qué tipo de errores/excepciones (que puedo imponer) provocaría un reinicio completo de una instancia? ¿Qué tipo de errores/excepciones mataría a una instancia para siempre?

Respuesta

11

El único motivo que hace que una instancia de rol sea reciclada (reiniciada) es cuando se cierra el método Run de RoleEntryPoint. Esto suele ocurrir cuando:

  1. overrided Run método

    (), y
  2. tienen una excepción no controlada en el código del programa, que causaría el método Run() para salir

Su papel, sin embargo sería reciclar , pero más bien cuelgue, cuando haya habilitado la colección de registros de IntelliTrace.

La plantilla predeterminada para un WebRole no anula el método Run(), dejando la implementación predeterminada, que es "Thread.Sleep (-1);". No hay evento (automático) que pueda ocasionar el reciclaje automático de roles de un WebRole. A menos que haga algo en su RoleEntryPoint, eso haría que el método Run salga. Este reciclaje automático solo ocurre con WorkerRole, que implementa el método Run().

ACTUALIZA 1 (según comentar 1)

run-Methoded of a RoleEntryPoint faces an error 

No es sólo un error, pero este tipo de error (es decir, una excepción no controlada), lo que hace que el método run() para salir. Además, no puede anular Run() en su WebRole, ya que su descendiente RoleEntryPoint vive en diferentes dominios de aplicaciones (incluso procesos diferentes) y luego en su aplicación web (por lo que no tendrá idea de las excepciones de su aplicación) . Obtenga más información sobre el alojamiento completo de IIS y el proceso here.

Por lo tanto, para un rol web que acaba de tener una aplicación web en características completas IIS 7.0/7.5, que no tiene idea de que este IIS es parte de una implementación de Azure. Global.asax es su lugar para gestionar los errores de aplicaciones web no controladas en ASP.NET. Consulte this question, cuya respuesta proporciona un buen ejemplo para el controlador Application_Error().

Puede usar el método estático RequestRecycle de tipo RoleEnvironment para solicitar manualmente el reciclaje de roles en su método Application_Error(). Sin embargo, no te recomiendo que lo hagas. No veo una buena práctica para reiniciar el servidor web debido a un error de aplicación. Debe implementar un buen manejo de excepciones y una estrategia de registro de errores, revisar periódicamente sus registros de errores y tomar medidas para evitar errores crípticos que requerirían el reinicio del servidor.

¿Cuál es su intención original? ¿Comprender cuándo se reciclará automaticamente un Rol, o modelar su aplicación para reciclar automáticamente su rol por error? Si es el último, le sugiero que revise los requisitos/lógica de su empresa.

ACTUALIZACIÓN 2

No puedo hablar de la boca de Neil, pero "fracaso instancia" es todo lo que puede causar una VM en ejecución para colgar. Instance en Windows Azure es una máquina virtual de signle que aloja el código de su aplicación (lea this blog post para obtener una explicación detallada sobre el Servicio alojado, Rol, Instancia). Su aplicación se ejecuta en un sistema operativo basado en Windows Server. Es una máquina virtual. Podría pasar cualquier cosa, desde una falla de hardware en el host hasta una falla genérica de software/controlador del sistema operativo invitado. No es necesario ser tu código. Por lo tanto, en caso de que ocurra algo que pueda causar el fallo de una única máquina virtual, la Tela de Windows Azure se encargará automáticamente de este problema. Si es necesario, su código se implementa automáticamente en otra máquina virtual. Y esto sucede automágicamente. No haces nada. Imagine que una unidad de disco duro se rompe, o un módulo de memoria se apaga, o una interfaz de red deja de responder: estos son solo algunos problemas simples que podrían causar la falla de una máquina virtual en ejecución. Esta es una falla de instancia.

Una falla en su código es algo de lo que debe encargarse. Todo lo demás: el controlador de Windows Azure Fabric se ocupa de.

ACTUALIZACIÓN 3

  1. ¿Qué ocurre con una aplicación asp.net en un WebRole si se produce una excepción y no se maneja? ¿La aplicación se bloqueará en un estado indefinido ("roto") hasta que lo busque o será terminado por el vm?

¡Esta pregunta está totalmente fuera de alcance! ¿Qué sucede con una aplicación asp.net en una cuenta de alojamiento compartido? ¿O en la instalación de IIS en las instalaciones? Accidente de aplicación para el usuario cuyas acciones causaron el bloqueo. El peor de los casos, la aplicación del grupo reciclar. Nunca he visto una aplicación asp.net "colgada". No hay tal cosa como "aplicación asp.net terminada" o "quebrada". Si se trata de un error genérico que se produce durante el inicio de la aplicación o la primera solicitud, la aplicación nunca estará en línea. Si es un error causado por una secuencia de acciones del usuario, el usuario verá un feo mensaje de error y nada más (a menos que tenga el manejador Application_Error() apropiado en su Global.asax. Creo que son explicaciones suficientes para una pregunta que no tiene nada que ver con Azure.

  1. ¿puede pensar en una pieza de código .NET en mi aplicación que podría provocar la caída de un papel o tela entera que no es posible con código administrado (aparte de un error desconocido en .NET)?

¿Es una broma? Este código se bloqueará su rol web y forzará un reciclaje:

RoleEnvironment.RequestRecycle() 

Acepte esta pregunta, ya que no creo que falte algo. Además, tiene respuestas a al menos 4 preguntas más, agregadas a la original.

FINAL

No hay tal cosa como "matar a la instancia siempre".

+0

Gracias. Tengo un pequeño problema al entender esto.Según usted, este reciclaje y reinicio automático solo puede ocurrir si el método run-Methoded de un RoleEntryPoint tiene un error. ¿Eso significa que una aplicación ASP.NET normal que se ejecuta en una función web no tiene posibilidad de reiniciarse automáticamente después de la falla (por ejemplo, una excepción no controlada)? Quiero decir que puedo anular opcionalmente el método de ejecución en una función web, pero esto no tiene sentido ya que el código de mi aplicación ASP.NET no se ejecuta en este método, ¿o estoy equivocado? – ceran

+0

Gracias de nuevo. Mi intención es solo la comprensión. Me pregunto acerca de un artículo escrito por Neil Mackenzie: _ "Los roles web y los roles de los trabajadores sirven respectivamente como entornos de alojamiento de aplicaciones para sitios web IIS y aplicaciones de larga duración. El poder de PaaS proviene del ciclo de vida de las instancias de roles administradas por Windows Azure En el caso de una falla en la instancia, Windows Azure reinicia automáticamente la instancia y, si es necesario, la recicla y gira una nueva VM "_. Esto suena como que todo sería fácil y automático. ¿Qué es un "error de instancia" en este caso? – ceran

+0

Ah, ya veo, las cosas se vuelven más claras ahora. Quedan 2 preguntas: ** 1 **. ¿Qué le sucede a una aplicación asp.net en un webrole si ocurre una excepción que no se maneja? ¿La aplicación simplemente se cuelga en un estado indefinido ("roto") hasta que la busco o la terminará la vm? ** 2 **. ¿Puedes pensar en una pieza de código .NET en mi aplicación que podría causar el bloqueo de un rol web completo o que no es posible con el código administrado (aparte de un error desconocido en .NET)? – ceran

Cuestiones relacionadas