O processamento do ASP.NET parou abruptamente no IIS 6.0

Question

Percebemos um comportamento bastante estranho em um de nossos aplicativos da Web. Ao depurar em uma estação de trabalho de desenvolvedor local, tudo é processado bem (usando o servidor da web de desenvolvimento da Cassini). Quando publicado em um servidor da web remoto usando o IIS 6.0, o processamento funciona bem cerca de 4 ou 5 minutos e depois morre abruptamente.

Explicarei mais tarde o que "morre abruptamente" significa, primeiro gostaria de dar um trecho do código falhado.

// loads data from SAP Webservice and serializes it into database    
LoadXMLDataFromSAP();

// loop each item of a certain structure and parse data
foreach (var xItem in xSapData)
{
    // method determining a status, about 30 LOC, fast execution
    GetStatusCodeForContract(xItem);

    ...

    // methods to parse data blocks, about 400 LOC, slow execution (database etc.)
    TimeconsumingParserMethod1(xItem);
    TimeconsumingParserMethod2(xItem);
}

Esse código está funcionando bem quando a depuração, a execução leva cerca de 13 minutos (tudo bem, porque ocorre apenas ao sincronizar todos os dados com o SAP). Ao executar o mesmo código contra o mesmo SAP-DataSource no IIS 6.0, a execução para após 4 ou 5 minutos.

Primeiro, o programa lança um sistema.nullReferenceException na chamada "TimecOnsumingParserMethod1 ()", no próximo loop, obtemos o System.NullReferenceException em "getStatuscodeForContract ()". Como usamos o mesmo parâmetro em ambas as chamadas, acho que a NullReferenceException é lançada porque o membro "xitem" é nulo.

Configuração do servidor:

8 Core Intel machine
4 GB of RAM
RequestTimeout = 900 (15 minutes)
Memory usage = unlimited

Alguém sabe sobre esse comportamento no IIS 6 ou em ambientes de servidores de produção similares?

Answer 1

Bem, finalmente rastreei o problema. Devido a alguns problemas com o EventLog em nosso servidor de testes locais, não notei algumas das exceções do IIS.

A raiz do problema não foi definida pelo tempo limite, é o comportamento de reciclagem do AppDomain do ASP.NET 2.0. Se você alterar muitas estruturas de pastas durante um WebRequest, o AppDomain será recarregado, o que leva aos misteriosos NullReferenceExceptions.

O artigo a seguir me ajudou a rastrear o problema: http://weblogs.asp.net/owscott/archive/2006/02/21/asp.net-v2.0-2d00-AppDomain-Recycles_2C00_-More-Common-Than-Before.aspx

O trecho de código abaixo do link é a solução alternativa usada (ele apenas desativa o monitoramento de arquivos para subpastas, alterações no web.config e Assemblys ainda recarregam o appDomain para implantação automática).

System.Reflection.PropertyInfo p = typeof(System.Web.HttpRuntime).GetProperty("FileChangesMonitor", System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Public | System.Reflection.BindingFlags.Static);

object o = p.GetValue(null, null);

System.Reflection.FieldInfo f = o.GetType().GetField("_dirMonSubdirs", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.IgnoreCase);

object monitor = f.GetValue(o);

System.Reflection.MethodInfo m = monitor.GetType().GetMethod("StopMonitoring", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic); m.Invoke(monitor, new object[] { });