Bug 351961

Description Sabine Neubauer 2011-07-13 08:29:12 EDT

Build Identifier: 

The following issue is already discussed in the newgsroup: http://www.eclipse.org/forums/index.php/t/219777/ . Because this is really a severe problem, I create this bug although we found a workaround. The description below is copied from the newsgroup post.

In our application (based on RAP 1.4) we need to activate UICallBack globally because we do not know in advance when UI updates are needed because they are triggered by user interactions.

Therefore, we activate the UICallBack in ApplicationWorkbenchAdvisor.postStartup() and add a SessionStoreListener for deactivating it and doing some cleanup.

Snippet:
public void postStartup() {
   UICallBack.activate(RWT.getSessionStore().getId());		
   RWT.getSessionStore().addSessionStoreListener(new SessionStoreListener(){            
            @Override
            public void beforeDestroy(SessionStoreEvent event) {
                UICallBack.deactivate(RWT.getSessionStore().getId());
                System.out.println(RWT.getSessionStore().getId() + ": before destroy");
            }
   });
}

Our observations are the following:
1. Reloading the page
- SessionStoreListener.beforeDestroy is called
- same UIThread is used afterwards
2. Session timeout page
- session timeout page appears
- clicking the link creates a new UIThread
- SessionStoreListener.beforeDestroy is never called and the former UIThread hangs
3. Closing browser/browser tab
- SessionStoreListener.beforeDestroy is never called and the UIThread hangs

After a while there are many hanging UIThreads and the sessions are never disposed. Hence, memory consumption increases with each session and it does not decrease.

Our current workaround is to maintain all created sessions by a singleton with application scope. A background thread validates them periodically (dependent on maxInactiveInterval) and invalidates the underlying HttpSession if the gap between current time and last accessed time is greater than maxInactiveInterval. If a session timeouts independently of our workaround it is removed from the list of maintained sessions. 

Reproducible: Always

Steps to Reproduce:
1. Create a project using the template RAP Application with a view
2. Adapt the postStartup like described above
3. Start the application with a very low time out
4. Observe the session timeouts