¿Por qué un trabajador enruta mi experiencia de generación de ASP.NET en ThreadAbortException durante una suspensión?

Question

Genero un hilo de trabajo en una aplicación ASP.NET que se ejecuta en Windows Server 2008, IIS 7.5 Lo primero que hace este hilo de trabajo es dormir durante N segundos, y luego hace su trabajo real. Durante el sueño, atrapa una ThreadAbortException.

Puede explicar este comportamiento, y los puntos de bonificación de que me apunte a cualquier configuración/ASP.NET IIS que se pueden utilizar para ajustar el comportamiento.

EDITAR: Más información. La sugerencia de atrapar ThreadAbortException me ayudó a solucionar el problema, así que gracias. Reescribí totalmente la redacción de esta pregunta en base a lo que aprendí, pero aún así, la misma pregunta, ¿POR QUÉ se interrumpe este hilo de trabajo durante un sueño?

Answer 1

A ThreadAbortException sucede en su hilo de trabajo porque alguien más llamó al Thread.Abort, por lo que probablemente no sea nada directamente lo que hizo su hilo de trabajo, sino una causa externa. El primer lugar que debe verificar es su propio código para cualquier gestión de hilos o abortos que pueda hacer. De lo contrario, para IIS, esto podría deberse a un proceso de trabajo (w3wp.exe) o al grupo de aplicaciones, o al reciclaje de AppDomain.

El reciclaje podría ser debido a la configuración para el grupo de aplicación, un reciclaje programado regularmente, o un uso del disparador de memoria/CPU tiempo de inactividad. Estos se pueden configurar a través del Administrador de configuración de IIS en Server Explorer (en Win 2K8) o simplemente ejecutando inetmgr.exe. Según el blog Tess' here, hay una serie de otras razones para dominio de aplicación de reciclaje:

• de Machine.Config, Web.Config o Global.asax se modifican
• El directorio bin o su contenido se modifica
• el número de re-compilaciones (aspx, ascx o asax) supera el límite especificado por el ajuste en machine.config o web.config (por defecto se establece en 15)
• el ph ruta ysical del directorio virtual se modifica
• La directiva CAS se modifica
• El servicio web se reinicia
• (2.0) Aplicación subdirectorios se eliminan

Esa entrada de blog también tiene información sobre cómo rastrear por qué sucedió un reciclaje. Para empezar, intente buscar en el registro de eventos (eventvwr.msc) para ver si hay información detallada.

También podría intentar depurar directamente el proceso de trabajo. Conectar el depurador de VS a la instancia w3wp.exe donde se ejecuta el código, añadir un punto de interrupción en Thread.Abort (puede que tenga que activar "paso a paso fuente de .NET Framework" en las opciones del depurador), y ver donde el Abort se origina mediante el uso de la ventana de pila de llamadas. Esto no le dirá por qué está sucediendo, pero al menos sabrá quién lo está haciendo.