2009-03-17 11 views
11

He escrito un HttpModule que genera un hilo de fondo. Estoy usando el hilo como una tarea programada que se ejecuta en proceso, lo que es realmente útil.¿Cuáles son algunas de las mejores prácticas para administrar subprocesos de fondo en IIS?

¿Cuáles son las mejores prácticas para realizar un seguimiento de este hilo? Nunca he hecho esto antes, y estoy un poco confundido acerca de algunos aspectos de la misma:

  1. ¿Cómo sé si el hilo sigue corriendo? Veo que hace su trabajo, pero ¿hay alguna otra manera de saber si todavía está vivo? Descargué ProcMon, pero w3wp.exe genera un boatload de subprocesos, así que no tenía idea de cuál era mi hilo. Lo llamé, pero eso no ayudó.

  2. ¿Cómo "atrapo" el hilo si se muere? ¿Hay algún tipo de método Dispose donde pueda hacer que escriba en EventLog o algo si falla? ¿Una "declaración de muerte" o algo así?

  3. ¿Cómo detengo activamente el hilo? Si quiero que deje de ejecutar este proceso en segundo plano, ¿cómo lo elimino sin tener que rebotar IIS?

  4. ¿Hay alguna forma de volver a iniciarlo, independientemente del HttpModule? (Supongo que la respuesta a esto es no ...)

Editar: Solo para aclarar, la intención es que mi hilo nunca desaparece. Se ejecuta una función, luego se va a dormir por un par de minutos, luego se despierta y ejecuta la función nuevamente. No es como si estuviera haciendo una tarea y luego terminara.

+0

¿Estás recibiendo un error system.timeout? – TStamper

+0

sin tener en cuenta. eso no debe aplicarse a esto – TStamper

Respuesta

6

Desde mi experiencia, puede hacer que esto funcione "suficientemente bien", pero no perfecto. Yo recomendaría implementar sus tareas repetitivas en un servicio de Windows. Dependiendo de lo que hagan las tareas, el Servicio de Windows tal vez ni siquiera tenga que hablar con la aplicación web o viceversa, e. gramo. si ambos trabajan con la misma base de datos. De lo contrario, todavía podría usar e. gramo. WCF para la comunicación.

La gran ventaja es: el servicio de Windows se iniciará con el sistema operativo, puede configurarlo fácilmente, iniciarlo y detenerlo mediante el panel de control, tiene monitorización incorporada a través del registro de eventos de Windows, puede actualizar el servicio en segundo plano y la aplicación web de forma independiente, etc.

Si esta no es una opción, e. gramo. debido a que se encuentra en un entorno de alojamiento compartido, recomendaría lo siguiente:

  1. Comience la secuencia de fondo en Application_start (Global.asax) y almacene la referencia de subproceso en una variable estática.
  2. Envuelva todos los métodos invocados en su hilo de fondo con try/catch, ya que desde .NET 2.0, cada excepción no controlada en un hilo de fondo cerrará la aplicación. (Se reiniciará en la próxima solicitud, pero ralentizará la siguiente solicitud, eliminará todas las sesiones y memorias caché actuales, y por supuesto no estará activo ningún temporizador hasta la siguiente solicitud).
  3. En cada solicitud (implementado tiene un HttpModule o en Global.asax nuevamente), verifique la instancia de Subproceso en la variable global (¿sigue siendo! = nulo, el subproceso está activo y ejecutándose, etc.). Si no, llame al código de reinicio. Use el bloqueo en la parte de reinicio para asegurarse de que el hilo no se creará dos veces al mismo tiempo.

Incluso entonces no puede estar seguro de que su hilo de fondo esté siempre en ejecución, si no tiene tráfico regular durante todo el día. También tenga en cuenta que, en un entorno de alojamiento compartido, es muy común cerrar grupos de aplicaciones si no hay actividad durante unas horas. Podría tratar de mejorar esto configurando una tarea programada en un equipo cliente en su propia red haciendo una solicitud HTTP ligera en su aplicación cada pocos minutos, solo para asegurarse de que su aplicación esté siempre en ejecución.

9

Cuando Jeff hizo Stackoverflow, tuvo un problema similar.

Su solución fue utilizar la caducidad del caché. Ponerías algo en el caché y luego, cuando caduque, se desencadena un evento en un hilo que no está orientado hacia el usuario. En el controlador de eventos para el vencimiento, usted se pega algo de código para volver a añadir el artículo a la memoria caché y hacer cualquier trabajo de limpieza que hay que hacer para su aplicación

Usando esta técnica, sus sub-preguntas son fáciles de responder:

  1. Compruebe que el artículo todavía está en caché.
  2. Si el artículo no está en caché, vuelva a agregarlo.
  3. Elimine el elemento de caché de la memoria caché.
  4. Agregue el elemento de nuevo a la caché.

Puede configurar una pequeña página de administración para configurar estas opciones.

Esto le proporciona una forma sencilla de gestionar el tiempo aproximadamente en su aplicación web. No requiere un Servicio de Windows separado, lo cual es una gran ganancia.

Cuestiones relacionadas