Graceful handling of server timeout in BlazeDS

Question

I have a flex client that makes service calls to a tomcat server running BlazeDS. I would like to gracefully handle server session timeouts in this environment.

I do have security constraints on the service, so the client authenticates against a remote object by initializing a ChannelSet based on the destination, and then logging in using that ChannelSet.

After the user is authenticated, if they go get a (long) cup of coffee, their session will inevitably time out.

I would like the client to detect the timeout, and return the user back to the login page, with the appropriate informational messages.

But I am having difficulty finding the best way to detect this timeout from the client. Is it possible, or must I have the server throw an error when the timeout occurs?

Thanks!

Adiel

Answer 1

We wrote a custom component for the client capturing Keystrokes and mouse events and then handle timeouts on the client.

Talley

There is no way to detect the timeout on the client side so this is the ideal solution. If you set the timeout on the client to be slightly less then the server this works really well. – Gymnosophist

Answer 2

We implemented a custom UI service which pings the server constantly (1 ping per 10 minutes) thus preventing AppServer from shutting down the connection. We also run some internal UI timer which is dropped each time any request is made (except the "ping" one) with a complete function calling UI to switch back to login and show "Session expired due to client inactivity".

Mares

Answer 3

This is not specific to BlazeDS, but as of Flex 4.5 (possibly earlier) there's a specific fault code on the fault event for timeout errors:

In your fault handler:

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

Codling

Answer 4

Look at the docs and see if an event is fired when the connection is disconnected. I would imagine that there is. If not, use try/catch around your connections and catch any connection related issues. If you do, redirect your app and notify the user. You will probably need to play with it to find the exact error codes being thrown for the connection issues but it should be fairly easy in debugging.

Lax

Answer 5

I encountered this issue on a project, particularly because BlazeDS had a different session timeout than the actual application (using a single-sign on architecture via ClearTrust). Due note, this was in a JBoss environment. I ended up taking a fairly simple approach by looking for 2 specific faultCodes in the fault handlers (had a base class with a common fault handler): DuplicateSessionDetected and DeliveryInDoubt. I saw the DuplicateSessionDetected whenever BlazeDS attempted to create a new session for the same JBoss session ID. DeliveryInDoubt tended to show up sometimes as well, but I'm not sure why. When I saw those fault codes, I then took the necessary action to refresh the app (depending on your needs, you could redirect to a login page or something else). Obviously, depending on the environment, you might have to listen for a different fault code, and this approach may not work in every situation given different environments/configs/etc.

Another approach that was discussed was to use a timer in the Flex app that would represent the BlazeDS timeout timer, but I'm not a fan of having timers sitting around for that purpose. I've also heard of sending a small bit of data back and forth to the server to check for a timeout, but again, that seemed less than ideal.

Annates

What version of BlazeDS are you using? – Adiel

Answer 6

I encountered this problem in one of my projects. What I did to overcome that is every time the client access to the server, either through RemoteObject or HTTPService, it checks first the user's authentication, if its already timed-out, it will return something and if its fine it will continue its process. In the client side's response handler result event, the client checks if the response is for timeout and if it is, it will forward to login page again. As far as I know there's no way the server will throw an error to the client when the user's session timed-out. You will just know the session timed-out on your next access to the server.

Parch

Answer 7

Implement the FlexSessionListener interface on the server-side. It provides a way to handle Flex session creation / destruction before they are actually done.

On the sessionDestroyed handler, use a messaging Producer to send a message from the server to the client letting him know that the session is about to time-out.

Defalcate

Problem with this is that the FlexSession and FlexClient abstract classes only expose a static way to listen for session/client create events. Looking at the code, the set of destroy listeners is not stored in the same static manner, so even overriding the classes won't provide an easy way to do this. Seems to me they naively gave the end users of the BlazeDS API an easy way to do this on the server way – Trochaic

Answer 8

Extend CallResponder, and override the fault method.

Check data.fault.faultCode for known error codes, such as ErrorMessage.MESSAGE_DELIVERY_IN_DOUBT.

If you get a hit, use the native function navigateToURL to redirect.

Trochaic