none
Problemas de overwhelming en Global.asax RRS feed

  • Pregunta

  • Buenos días.

    Tenemos una aplicación en asp.net (c#) frente a una bd SQLServer2000.

    De un tiempo a esta parte, de forma completamente aleatoria, se producen cierres de sesión masivos.
    Tras logear el motivo de esos cierres (información obtenida de http://weblogs.asp.net/scottgu/) llegamos a obtener la siguiente información:

    _shutDownMessage=Overwhelming Change Notification in C:\Inetpub\wwwroot\apg Change in GLOBAL.ASAX CONFIG change
    _shutDownStack=   at System.Environment.GetStackTrace(Exception e)   at System.Environment.GetStackTrace(Exception e)   at System.Environment.get_StackTrace()   at System.Web.HttpRuntime.ShutdownAppDomain() at System.Web.HttpApplicationFactory.OnAppFileChange(Object sender,FileChangeEvent e)   at System.Web.DirectoryMonitor.OnFileChange(FileAction action, String fileName)   at System.Web.DirMonCompletion.OnFileChange(FileAction action, String fileName).

    Es decir, que se estan produciendo cambios masivos en el Global.asax, sin embargo dicho fichero no se ha cambiado y tampoco tenemos ningun antivirus o sistemas de backup que accedan a dicho fichero. El tema se vuelve aun mas extraño, puesto que quitamos todos los permisos a todos los usuarios para ese fichero e incluso lo marcamos como de solo lectura, no obstante siguen produciéndose cierres de sesion por este motivo.

    (Estamos pensando en anular el FileChangeMonitor para evitar que chequee ese fichero, no obstante esto no solucionaría el problema : ¿Qué hace que el sistema crea que se han producido cambios masivos en el global.asax cuando en realidad no ha cambiado?

    Cualquier ayuda o idea será bien recibida.

    Muchas gracias.

    Saludos.
    miércoles, 17 de septiembre de 2008 9:30

Todas las respuestas

  • Sospecho que el mensaje es engañoso, y que no es en el global.asax donde se producen los cambios, sino en algún otro sitio de la aplicación web. ¿Puede ser que tengas algún subdirectorio de la web donde grabes muchos ficheros mientras la aplicación está en marcha?

     

     

    miércoles, 17 de septiembre de 2008 20:49
  • Buenos dias.

    Hola Alberto.

    Solo tenemos un subdirectorio en el cual se exportan datos a hojas Excel, pero estamos hablando de variaciones de generar 1 fichero o 2 al mes, y de ser este el motivo el cierre de sesión debería de producirse cuando se exportan datos, no de forma aleatoria.(con un solo usuarios tirando de la aplicación, aleatoriamente le cierra la sessión, puede estar trabajando 3 dias sin ningún problema y otro le cierra la sesión cada dos por tres, de forma completamente aleatoria).
    Tambien tenemos un fichero de log (utilizando el log4net), pero los logs se generan en el directorio raiz. El log esta configurado para un maximo de 10 ficheros de 5 MB cada uno, hemos hecho pruebas de saturar el log, es decir, de llegar a llenar los 10 ficheros y que vuelva a reescribir en el 1º y así sucesivamente, y no se producen cierres de sessión. Otra prueba fue anular el log, y seguían produciéndose cierres de sessión.

    Para mas información, te diré que se desarrolló con Visual Studio 2003 con el Framework 1.1.

    En ocasiones, de forma muy exporádica, el cierre de sesión se debe a lo siguiente:

    Tipo de suceso:   Error

    Origen del suceso:             .NET Runtime

    Categoría del suceso:       Ninguno

    Id. suceso:            0

    Fecha:                   12/09/2008

    Hora:                     16:06:03 Usuario:                               No disponible Equipo: IT_PC92 Descripción: No se encuentra la descripción del Id. de suceso ( 0 ) en el origen ( .NET Runtime ). Es posible que el equipo local no tenga la información de Registro o archivos DLL de mensajes necesarios para mostrar mensajes desde un equipo remoto. Es posible que pueda usar el indicador /AUXSOURCE= para recuperar esta descripción; consulte Ayuda y soporte técnico para obtener más detalles. La siguiente información es parte del suceso:

    _shutDownMessage=

    _shutDownStack=.



    como se puede ver, no hay forma de saber que es lo que ha ocurrido.

    En la mayoría de las ocaciones, el mensaje de error que obtenemos es el del mensaje anterior (con la misma "cabecera" que este, pero con información para el shutDown y para el shutDownStack.

    Para más infotrmación comentar que cuando se producen los cierres nunca pasa por el Application_Error, es decir, recicla el aspnet_wp.exe sin que aparentemente sea un error del código de la aplicación, y lo recicla por que a su entender, se han producido muchos cambios en un fichero, aunque en realidad no se haya tocado.

    ¿Le ha pasado algo parecido a alguien?
    ¿Alguna idea de cómo abordar el problema?.

    Saludos.
    Fabián.


    jueves, 18 de septiembre de 2008 7:46
  •  Fgonzalez Escribió:
    ¿Le ha pasado algo parecido a alguien?

     

    Pues me había pasado algo que yo creía que era parecido, pero por lo que me comentas, no es tu caso.

     

    A mí lo que me pasaba es que estábamos copiando muchos ficheros a un subdirectorio de la web (en mi caso eran archivos html con ciertas páginas de contenido estático que se cambiaban con frecuencia). Al hacer esto, la aplicación se reiniciaba y se perdían las sesiones. Al final el remedio fue sustituir el directorio físico que contenía estos archivos por un enlace simbólico sobre el sistema de archivos apuntado a una carpeta externa, con lo que el detector de cambios de aspnet ya no se daba cuenta de los cambios, pero a IIS no le molestaba y seguía siendo capaz de servir esos archivos.

     

    Pero me temo que esto no te resulta muy útil, ya que según me dices no estás cambiando archivos de la web, así que te tiene que estar pasando algo diferente.

     

    jueves, 18 de septiembre de 2008 8:38