asp.net, stateerver, NLB, sesión perdida

Question

Primera publicación en stackoverflow, espero tener excelentes comentarios :)

Actualmente estoy intentando equilibrar la carga de nuestro sitio web. Hemos configurado un NLB de 2 clústeres en Windows Server 2003 con IIS 6.

Mientras probaba la configuración, descubrí que a veces, nuestra sesión se pierde. Un día y medio después, aquí está el resultado:

1. Sí, nuestra machine.config tiene la misma clave de cifrado / descifrado.
2. Sí, la identificación en iis metabase.xml es la misma para ambas máquinas. En realidad, todo el archivo es el mismo, excepto "AdminACL".
3. Ambas aplicaciones web están configuradas con "StateServer" y ambos apuntando a la misma máquina.

Desde ese punto, la búsqueda en Google proporciona menos información y posibles soluciones.

Por lo que sé, no hay un patrón particular que cause este problema. Simplemente sucede de vez en cuando.

Al intentar encontrar el problema, he visto que una solicitud envió la cookie de id de sesión asp al servidor, pero el servidor no la asignó a la sesión de usuario.

Entonces, el número de solicitud x fue enviado desde el cliente, con la cookie, se asignó la sesión y todo salió sin problemas. El número de solicitud x + 1 se envió desde el cliente, con la cookie, pero no se encontró la sesión.

Ambas solicitudes se realizaron en la misma máquina en el NLB.

Aquí hay un fragmento de asp trace.axd:

Primera solicitud:

Detalles de la solicitud Id. De sesión: j2ffvy45updpc52uhw1mbg55 Tipo de solicitud: GET Hora de la solicitud: 26/11/2008 2:58:06 PM Código de estado: 200 Codificación de solicitud: codificación de respuesta Unicode (UTF-8): codificación de Unicode (UTF-8)

Solicitar colección de cookies

Nombre Valor Tamaño

ASP.NET_SessionId j2ffvy45updpc52uhw1mbg55 42 AYUDA 22 9

Colección de cookies de respuesta

Nombre Valor Tamaño

Colección de encabezados

Nombre Valor

Cookie ASP.NET_SessionId = j2ffvy45updpc52uhw1mbg55; AID = 22

Segunda solicitud:

Detalles de la solicitud Id. De sesión: Tipo de solicitud: POST Hora de la solicitud: 26/11/2008 2:58:08 PM Código de estado:
Codificación de solicitud: codificación de respuesta Unicode (UTF-8):

Solicitar colección de cookies

Nombre Valor Tamaño

Colección de cookies de respuesta

Nombre Valor Tamaño

Colección de encabezados Nombre Valor Cookie ASP.NET_SessionId = j2ffvy45updpc52uhw1mbg55; AID = 22

Como puede ver en la segunda solicitud, la cookie se envía desde el cliente, pero parece que asp nunca agrega las cookies en su "Solicitar colección de cookies". Creo que por eso no encuentra la sesión.

Entonces, ¿por qué la cookie no está asignada a la sesión? ¿Ese es el problema? ¿El problema está en otra parte?

No dude en hacer cualquier aclaración.

Gracias a todos por sus comentarios.

JF

Answer 1

Finalmente encontré la respuesta a mi problema. Su origen está dentro del código de la aplicación (como el 99% de los 'errores' de herramientas de terceros de un programador). Decidí publicarlo de todos modos en caso de que alguien se encuentre en un escenario similar.

Este código era parte de la clase WebServiceRequester. La clase solicitante del servicio web se instanciaba cuando se creaba la sesión y se guardaba en la sesión. Durante la creación, inicializamos el miembro 'm_webServiceURL', y este miembro se guarda en la sesión posterior. El valor de inicialización de este miembro dependía de la configuración de la máquina local.

La parte importante es la siguiente: La clase WebServiceRequester contiene un objeto WebService. Los objetos de WebService no se pueden guardar en la sesión, no son serializables en asp. La propiedad tenía el atributo [No serializado]. Por lo tanto, cada vez que accedimos a la propiedad 'WebService' del objeto por primera vez durante un ciclo de vida de la página, tuvimos que crear uno nuevo y asignarle la url 'm_webServiceURL' que se guardó en la sesión. Como puede ver, un nuevo objeto de servicio web, posiblemente en una máquina diferente, lo que significa una configuración diferente en cada máquina.

así que esto es lo que sucedió: el cuadro 29 se configuró para acceder al servicio web en localhost

El

cuadro 30 se configuró para acceder al servicio web como 192.168.253.29.

Técnicamente, ambos están configurados en la misma máquina. Pero aquí hay un escenario:

inicie sesión en el cuadro 29. m_webServiceURL está configurado como localhost en la sesión.

[alguna solicitud en la casilla 29 aquí]

El equilibrio de NLB nos trae a la casilla 30. box 30 carga su sesión, crea un nuevo servicio web obedece con localhost como la dirección del servicio web. el cuadro 30 realizó la solicitud al servicio web incorrecto que condujo a una excepción de sesión expirada.

Uno de los problemas durante la depuración fue que la comunicación local no se grabó con el monitor de red.

Lo que me llevó a la traza, fue que nunca tuvimos una excepción registrada en la casilla 29 traza de registro, como debería haberlo hecho.

Gracias por sus sugerencias a todos, fue muy apreciado.

Que tengas un buen día. JF

Answer 2

No es estrictamente una respuesta a su pregunta, pero ¿lo ha intentado utilizando un almacén de sesión basado en un servidor SQL? (Busque en MSDN el script permanente en lugar del script temporal que se proporciona con asp.net)

He escuchado "cosas malas" sobre el servicio de sesión ejecutable y, en consecuencia, no lo he usado. Sin embargo, nunca tuve ningún problema con la solución basada en servidor SQL.

Lo sentimos, no es estrictamente una respuesta a su problema, pero debería (a) solucionarlo o (b) reducirlo significativamente.

Answer 3

Bueno, si está utilizando Visual Studio, al menos podría probarlo con MSDE (la versión reducida de SQL Server que viene con Visual Studio) ...

Podría ayudar a descartar problemas con el servidor de estado ...

Answer 4

El uso del enfoque de base de datos tiene sus propios problemas. Creo que debería poder utilizar su enfoque preferido.

Quizás este artículo de solución de problemas de sesión ayudaría?

O " Solución de problemas relacionados con la sesión en ASP.NET "

O " Solución de problemas de estado de sesión ASP.NET caducado y sus opciones "

Answer 5

Seré cojo y repetiré la propuesta de MS SQL Server. Instale SQL Server Express, que es completamente gratuito, incluso para uso comercial, y solo tiene estos 3 inconvenientes que no deberían ser un problema para usted en esta etapa:

• Base de datos de tamaño máximo de 4 GB
• Max 1 CPU Core usado
• Máx. 1 GB de RAM utilizada

Answer 6

Algunos puntos a tener en cuenta:

• ¿Cuál es la carga en su sitio web? State Server tiene la tendencia a bloquearse cuando se enfrenta a una gran cantidad de visitas simultáneas. Solo lo usamos en escenarios en los que tenemos un número muy pequeño de usuarios (en los años 10, en su mayoría sistemas de back-end). Cada vez que intentamos usarlo en producción para sitios que atienden diariamente a miles de usuarios, se bloquea y se pierde la información de la sesión.
• En uno de los entornos de producción que administramos, estamos utilizando MSSQL 2005 Express para administrar las sesiones, el sitio tiene más de 10 000 usuarios al día y más de 200 000 páginas al día. Este es un enfoque recomendado en caso de que la sesión sea imprescindible y esté estrechamente vinculada a su aplicación.

Si está a punto de utilizar MSSQL Express como su base de datos de estado, recuerde que no viene con el Agente SQL Server, lo que significa que no hay ningún programador de tareas ejecutándose en segundo plano y limpiando sus sesiones caducadas. Recomiendo encontrar un programador y ejecutar el procedimiento almacenado de sesiones caducadas limpias periódicamente.

Buena suerte

Answer 7

En lugar de perder el tiempo con SQL, envíe sus pruebas directamente a uno de sus nodos IIS para ver si aún tiene el mismo problema. Estoy seguro de que si solo realiza un pequeño número de pruebas StateServer no será el problema.

Answer 8

Intente configurar el nombre de dominio del asp.net_sessionid a través del código en " .yourdomain.com " ;. De forma predeterminada, el nombre de dominio de la cookie ASP.net_SessionID se establece en la ruta completa de la aplicación. Entonces, esta puede ser una de las razones por las cuales la cookie no viaja.

Por ejemplo. Request.Cookies [" ASP.NET_SessionId "]. Domain = " .yourdomain.com " ;. Recuerda el primer ". & Quot; es importante en el nombre de dominio.

Puede hacer esto en el HttpModule en el evento AcquireRequestState.