2012-01-25 8 views
7

Tengo un problema de producción con el estado de la sesión In-Proc.MVC3 .NET Session perdiendo aleatoriamente el valor de la sesión y devuelve como nulo

Nuestra aplicación se basa en el framework MVC 3 .NET y está integrada en nuestro sitio que ejecuta Sitecore CMS.

Nuestros usuarios han estado experimentando "Referencia de objeto no establecida en una instancia de un objeto" al azar a través del flujo de la aplicación.

Después de un extenso registro y seguimiento, podemos concluir que esto se produjo cuando el objeto de sesión devuelve nulo.

Aquí hay algunos detalles sobre lo que encontramos y lo que sabemos.

  1. La ID de sesión persiste para el mismo usuario y ha pasado correctamente todos los en la aplicación.
  2. No creo que esto sea un problema de código, porque esto solo ocurre en la producción en intervalos aleatorios, nunca ocurre en un entorno local, de desarrollo o de transición.
  3. Hay dos servidores de producción ejecutándose a través de un equilibrador de carga.
  4. No es un problema persistente del servidor, ya que lo probamos durmiendo en uno de los servidores y teniendo toda la ruta de tráfico a un servidor. También a través del registro podríamos identificar que el usuario está accediendo al mismo servidor, pero la sesión se ha vuelto nula.
  5. Esto tampoco parece ser un problema para el cliente, ya que pueden realizar correctamente la aplicación incluso si han encontrado un error anteriormente.
  6. Esto no parece ser una carga de tráfico o un problema de carga del servidor, ya que ocurre a lo largo del día en momentos aleatorios, y le sucede a los usuarios aleatorios durante.
  7. Esto no parece ser causado por el reciclaje del grupo de aplicaciones.
  8. Esto no parece ser causado por el tiempo de espera de la sesión, ya que hemos establecido que el tiempo de espera sea de dos horas y mientras rastreamos el registro, los usuarios pueden experimentar este 5-10min en el flujo.

Nota al margen: debemos usar el estado de la sesión In-Proc debido a nuestro Sitecore CMS. Entonces, cambiar el diseño no es una opción.

Tengo una teoría que podría tener algo que ver con el bloqueo de la sesión o la corrupción de los intentos de acceso concurrentes.

Un pequeño lugar en el que vemos la ocurrencia de este problema desde nuestra aplicación es cuando los usuarios están siendo redirigidos por un javascript (windows.location).

Y en áreas donde se realizan llamadas async ajax.

Nos hemos estado rascando la cabeza en esto por un tiempo, me pregunto si alguien por ahí tendría alguna idea o teoría de lo que podría ser el problema?

Gracias

Agregado Nota:

@Mystere & & @ H27Studio, Así que también he descubierto algo relacionado con problemas de restablecimiento sessionId o sesión.En algunos casos descubrimos que en una página redirigir está activando dos llamadas GETS duplicadas al método, con la primera llamada que falta un ID de sesión y se redirige aleatoriamente a uno de los servidores (Esto se debe a que la sesión persistente del servidor del equilibrador de carga es base en IP del cliente, ID de sesión y otra información del encabezado para crear una sesión única para mantener un cliente en un servidor). Esto ocurre cada vez durante el flujo cuando nuestra página de redirección está utilizando una ventana.location.

Esto causará el problema "Referencia del objeto no establecido .." para el cliente si la llamada no es válida, no sessionID golpea el mismo servidor. (Esto probablemente porque la primera llamada incorrecta sin sessionID está causando que la aplicación cree una nueva sesión que anula el objeto de la sesión original). Incluso en la segunda llamada donde el sessionID correcto pasa a la aplicación, descubriremos que el objeto de sesión contiene null .

Así que creo que hay un problema con la llamada duplicada que está limpiando el objeto de la sesión, que no está seguro de por qué o por qué está comenzando.

¿Alguien tiene idea de esto? Gracias

Actualización: Estamos planeando seguir estos pasos con la esperanza de resolver este problema.

  1. Tenemos problemas en las áreas donde se realizaron llamadas Async Ajax, por lo que estamos planeando eliminar la función Async y dejar que el Ajax se ejecute en sincronización.
  2. Tenemos problemas donde una redirección de JavaScript de Windows.location está sucediendo. Hemos creado un método alternativo utilizando la devolución de datos con la esperanza de solucionar el problema en esta área.
  3. Otras áreas, que no están relacionadas con uno de los problemas anteriores todavía están en el aire.

El efecto del cambio se publicará una vez que lo implementemos en producción.

Gracias por todos los comentarios.

+0

No confíe en el tiempo de espera de la sesión. Si el servidor necesita más memoria, liberará las sesiones. Tengo 1 hora establecida en mi trabajo, y todavía la mayoría de las personas pierden sesiones antes de los 20 minutos, y algunas veces en 5-10. (Y es una máquina con 69Gbs de RAM, y no mucho tráfico ...) – H27studio

+0

Mi compañía ha estado rascándonos la cabeza por esto también, incluso después de 'elmah' logging, etc. usando 'inproc' ... –

+2

@ H27studio, ¿tiene referencia para "Si el servidor necesita más memoria, liberará las sesiones"? –

Respuesta

5

Después de meses de búsqueda y depuración, creo que finalmente llegamos a una conclusión. Parece que hay un error con el tiempo de espera de la sesión de Sitecore Analytics Robots. Primero notamos que cada vez que la sesión aleatoria se perdía debido a que la sesión se agotaba prematuramente, notamos que estas sesiones se estaban ajustando a un tiempo de espera de 1min en lugar de a 120min.

Después de buscar en todos los archivos de configuración, notamos que Sitecore Analytic.Robots.SessionTimeout fue el único valor de tiempo de espera establecido en 1min.

Al aumentar este valor, se solucionó el problema de tiempo de espera de la sesión.

Así que el problema fundamental es Sitecore Analytics está identificando erróneamente alguna sesión de visitante como sesión de robot y reasignando su tiempo de espera a 1min. Este es probablemente un error para informar.

Actualización: Respuesta de Sitecore:

Sitecore CMS fue diseñado para ser utilizado con la tecnología ASP.NET Web Forms. Al usar formularios web, la detección de bot depende del control en la página. Es natural que no pueda usarlo en la aplicación ASP.NET MVC, pero hay una solución fácil: coloque el siguiente código dentro del elemento:

<% 
if (Context.Diagnostics.Tracing || Context.Diagnostics.Profiling) 
{ 
    Response.Write("<!-- Visitor identification is disabled because debugging is active. -->"); 
} 
else if (Tracker.IsActive && (Tracker.Visitor.VisitorClassification == 925)) 
{ 
    Response.Write("<link href=\"/layouts/System/VisitorIdentification.aspx\" rel=\"stylesheet\" type=\"text/css\" />"); 
} 
%> 
0

Creo que su problema pueden ser las llamadas Async ajax que usted alude. Leí un artículo de David Hayden recientemente que hablaba sobre problemas con solicitudes concurrentes de ajax en la misma sesión, lo que causaba problemas. Es algo para mirar de todos modos. Espero que ayude

http://davidhayden.com/blog/dave/archive/2011/02/09/SessionLessControllersMvc3.aspx

Habla de que justo al final del post.

+0

Las solicitudes Ajax no están causando problemas, solo se ejecutarán una después de otra en el servidor para evitar el acceso paralelo, cuando el estado de la sesión esté habilitado. Eso es un problema de rendimiento y no está relacionado con la pregunta de OP con la desaparición de sesiones. – Jan

+0

He leído este artículo y pensé que podría ser un problema también, pero como dijo Jan. Los estados de sesión deben obtener el bloqueo si está en un estado de lectura/escritura. Por lo tanto, la solicitud concurrente de ajax simplemente tendrá que ejecutarse en orden. No debería estar corrompiendo la sesión. Incluso si esta fuera la causa, creo que ocurriría en una base constante en lugar de aleatorio.Pero esta es un área en la que confío menos, ¿tal vez alguien tiene un buen método para mí para verificar si este es el problema? Gracias –

+0

Problema de rendimiento sí, pero también mencionó que la sesión puede dañarse y por eso lo mencioné. Sólo trato de ayudar. – Perry

Cuestiones relacionadas