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.
- La ID de sesión persiste para el mismo usuario y ha pasado correctamente todos los en la aplicación.
- 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.
- Hay dos servidores de producción ejecutándose a través de un equilibrador de carga.
- 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.
- Esto tampoco parece ser un problema para el cliente, ya que pueden realizar correctamente la aplicación incluso si han encontrado un error anteriormente.
- 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.
- Esto no parece ser causado por el reciclaje del grupo de aplicaciones.
- 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.
- 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.
- 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.
- 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.
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
Mi compañía ha estado rascándonos la cabeza por esto también, incluso después de 'elmah' logging, etc. usando 'inproc' ... –
@ H27studio, ¿tiene referencia para "Si el servidor necesita más memoria, liberará las sesiones"? –