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!

Answer 1

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.

Answer 2

I'd like to know if anyone ever found a proper solution for this. the Consumer does have a disconnect event that's triggered and blazeds sends over a very specific error message saying the session has timed out. My application show the login screen properly, great.

Problem is, when I try to relog back in, there's nothing being sent to the server. Like if the consumer can't connect back to the server. Is there something the consumer needs to do? I tried a slew of things but always with the same results. Only way to make it work is to refresh the browser.

Answer 3

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.

Answer 4

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

Answer 5

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.

Answer 6

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.

Answer 7

@ lonut-Maxim: Can I have a good example of handling FlexSessionListner on server side?

Answer 8

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".