La sesion ha caducado - La pagina se recargará. - HTTP 440.

Hicimos una migración de un sistema que estaba en producción en GeneXus Evolution 2 a GeneXus con Evolucion 3 WEB y generando con C#.

Ademas de la versión, teníamos con diferencia que en Evo2 teniamos la propiedad de "Javascript Debug Mode" = Yes y al pasar a Evo3, la dejamos en NO, para mejorar un poco la seguridad.

Instalamos la parte batch y los web services y todo funcionaba correctamente. 
Cuando instalamos los web forms  en producción empezo a aparecer en la pantalla de los usuarios, "La sesión ha caducado. La pagina se regargará". 

Esto era a pesar que teníamos la propiedad "On Session Timeout" = Ignore.

Esto nos obligó a volver atrás dicha instalación y regenerar todo con la propiedad "Javasript Debug Mode" = YES y "On Session Timeout" = Ignore. Dichas propiedades OBLIGAN  a un Rebuild all de toda la aplicación, pues afectan tanto la compresión de los javascript como el uso o no de trafico encriptado en los request AJAX. 

Los colegas de GeneXus estuvieron viendo el caso, pues era un problema bastante difícil de reproducir. (**) 

La instalación estaba formada por 4 nodos con un balanceador de carga (NLB) configurado para que mantenga la afinidad, por lo que después que un nodo atiende a un cliente, lo sigue atendiendo el mismo nodo por un tiempo largo. 

El problema que encontraron fue que como teníamos mas de un working process (3) atendiendo al directorio virtual (WEB Garden) y usábamos servidor de sesiones "In Process", cada working process tenia un conjunto de variables de sesiones. 

Esto traía como consecuencia, que a pesar que se mantenía el servidor que nos atendía, si se cambiaba de working process, se perdían las variables de sesión y por lo tanto, el sistema reaccionaba con un error 440, pues no podía desencalabrinar el trafico AJAX pues esto se encripta y desencripta con una clave generada y guardada en las variables de sesión. También se pierden otras variables de sesión, pero en esta aplicación no son criticas, pues se usan para guardar estado de filtros y poca cosa mas. 

Resumiendo, si se usan variables de sesión o se quiere tener el trafico AJAX encriptado se debería configurar:

* Solo un working process por directorio virtual
* NLB con Affinity

Si quisiéramos tener mas de un working process o no tener Affinity en el NLB, hay que configurar el servidor de estado como servicio, cambiando el web.config y poniendo

 <system.web>
    <sessionState mode="StateServer"
      stateConnectionString="tcpip=SampleStateServer:42424"
      cookieless="false"
      timeout="20"/>
  </system.web>

Hay que tener precauciones con este servicio y hacerlo tolerante a fallas, pues se agrega un punto de falla centralizado por lo que dicho servicio.

Hay varias cosas que pueden mejorarse en todo esto. 
En la configuración:
* Configurar un servidor de sesiones centralizado y tolerante a fallas. 

En GeneXus
* Usar una clave de encriptacion de trafico que no se guarde en variables de sesión. 
* Usar un código diferente al HTTP 440 cuyo texto es Session Timeout, en el caso que no pueda desencriptar los parámetros AJAX. 
* Que al cambiar la propiedad "Javascript Debug Mode" de YES a NO, no sea necesario un Rebuild all, sino que se tome del web.config alguna propiedad (esto no se si es posible, pero estaria bueno). 

En la documentación
* Documentar mejor en que casos puede darse el mensaje "La sesion ha caducado y la pagina se recargara" y que puede hacer para evitarlo. 

-------------------------------------------------
** Gracias Sabrina y Gonzalo por descubrir el problema!


Links relacionados

  • Session State Modes - https://msdn.microsoft.com/en-us/library/ms178586.aspx
  • Javascript Debug Mode - http://wiki.genexus.com/commwiki/servlet/wiki?17384,Javascript%20Debug%20Mode%20property
  • On Session Timeout - http://wiki.genexus.com/commwiki/servlet/wiki?17458,On%20Session%20Timeout%20property


Comentarios

  1. Hola Enrique, Muy bueno el articulo!

    Nosotros en cambio preferimos usar SQL donde guardar la sesión y no el servicio de stateserver, ya que este no es escalable. Seguramente perdemos un poco como velocidad en comparación si medimos una sola llamada pero en el complejo ganamos en escalabilidad.
    El problema de escalabilidad que encontramos es en la cantidad de memoria que utilizaba cuando aumentábamos la cantidad de usuarios conectados a los diferentes servidores.



    Saludos

    ResponderEliminar

Publicar un comentario

1) Lee el post
2) Poné tu opinión sobre el mismo.
Todos los comentarios serán leidos y la mayoría son publicados.

Entradas más populares de este blog

Paleta de colores en GeneXus

Impresión directa a impresora en el WEB con aplicaciones GeneXus.