Gestión elegante del tiempo de espera del servidor en BlazeDS

Question

Tengo un cliente flexible que realiza llamadas de servicio a un servidor tomcat que ejecuta BlazeDS. Me gustaría manejar con gracia los tiempos de espera de la sesión del servidor en este entorno.

Tengo restricciones de seguridad en el servicio, por lo que el cliente se autentica frente a un objeto remoto al inicializar un ChannelSet basado en el destino y luego iniciar sesión usando ese ChannelSet.

Después de autenticar al usuario, si obtienen una taza (larga) de café, su sesión inevitablemente terminará.

Me gustaría que el cliente detecte el tiempo de espera y devuelva al usuario a la página de inicio de sesión con los mensajes informativos apropiados.

Pero estoy teniendo dificultades para encontrar la mejor manera de detectar este tiempo de espera del cliente. ¿Es posible, o debo hacer que el servidor arroje un error cuando ocurre el tiempo de espera?

Gracias!

Answer 1

Mire los documentos y vea si se desencadena un evento cuando se desconecta la conexión. Me imagino que existe. De lo contrario, use try/catch alrededor de sus conexiones y detecte cualquier problema relacionado con la conexión. Si lo haces, redirige tu aplicación y notifica al usuario. Probablemente necesites jugar con él para encontrar los códigos de error exactos que se lanzan para los problemas de conexión, pero debería ser bastante fácil en la depuración.

Answer 2

Encontré este problema en un proyecto, particularmente porque BlazeDS tenía un tiempo de espera de sesión diferente al de la aplicación real (usando una arquitectura de inicio de sesión único vía ClearTrust). Nota debida, esto fue en un entorno JBoss. Terminé tomando un enfoque bastante simple al buscar 2 códigos de falla específicos en los manejadores de fallas (tenía una clase base con un manejador de fallas común): DuplicateSessionDetected y DeliveryInDoubt. Vi que DuplicateSessionDetected cada vez que BlazeDS intentaba crear una nueva sesión para el mismo ID de sesión de JBoss. DeliveryInDoubt también apareció a veces, pero no estoy seguro de por qué. Cuando vi esos códigos de falla, tomé las medidas necesarias para actualizar la aplicación (dependiendo de sus necesidades, podría redireccionar a una página de inicio de sesión u otra cosa). Obviamente, dependiendo del entorno, es posible que tenga que escuchar un código de falla diferente, y este enfoque puede no funcionar en todas las situaciones dadas diferentes entornos/configuraciones/etc.

Otro enfoque que se discutió fue utilizar un temporizador en la aplicación Flex que representaría el temporizador de tiempo de espera de BlazeDS, pero no soy partidario de tener temporizadores sentados para ese fin. También he escuchado sobre enviar un poco de información al servidor para verificar el tiempo de espera, pero una vez más, eso parecía menos que ideal.

Answer 3

Escribimos un componente personalizado para que el cliente capture las pulsaciones de teclas y los eventos del mouse y luego manejamos los tiempos de espera en el cliente.

Answer 4

He encontrado este problema en uno de mis proyectos. Lo que hice para superar eso es que cada vez que el cliente accede al servidor, ya sea a través de RemoteObject o HTTPService, primero verifica la autenticación del usuario, si ya ha agotado el tiempo de espera, devolverá algo y, si está bien, continuará su proceso. En el evento de resultado del manejador de respuesta del lado del cliente, el cliente verifica si la respuesta es de tiempo de espera y si lo está, se reenviará a la página de inicio de sesión nuevamente. Por lo que sé, no hay manera de que el servidor arroje un error al cliente cuando la sesión del usuario agotó el tiempo de espera. Simplemente sabrá que la sesión se agotó en su próximo acceso al servidor.

Answer 5

Implemente la interfaz FlexSessionListener en el lado del servidor. Proporciona una forma de manejar la creación/destrucción de sesiones Flex antes de que realmente se realicen.

En el controlador de sesión destruida, utilice un Productor de mensajería para enviar un mensaje del servidor al cliente informándole que la sesión está a punto de agotarse.

Answer 6

Implementamos un servicio de IU personalizado que hace ping al servidor constantemente (1 ping por 10 minutos) impidiendo así que AppServer cierre la conexión. También ejecutamos un temporizador de IU interno que se elimina cada vez que se realiza una solicitud (excepto el "ping") con una función completa que llama a la IU para volver a iniciar sesión y mostrar "La sesión expiró debido a la inactividad del cliente".

Answer 7

Esto no es específico de BlazeDS, pero a partir de Flex 4.5 (posiblemente anterior) hay un código específico de fallo en caso de fallo de los errores de tiempo de espera:

En el administrador de fallos:

if(faultEvent.fault.faultCode == "Client.Error.RequestTimeout"){ 
    trace("TIMEOUT ERROR"); 
} 

Answer 8

Extend CallResponder, y anula el método de falla.

Compruebe data.fault.faultCode para conocer los códigos de error conocidos, como ErrorMessage.MESSAGE_DELIVERY_IN_DOUBT.

Si recibe un golpe, use la función nativa navigateToURL para redirigir.