Community
Participate
Working Groups
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
What servlet engine are you using?
My observations regarding how different servlet engines behave when there is a standing callback requests: * Jetty 6.1.x does not invalidate the session while there is a callback request standing * Jetty 7.4.x does not invalidate the session while there is a callback request standing * Tomcat 7.0.12 *does* invalidate the session even though there is a callback request standing Jetty 7 and Tomcat ran as embedded servlet engines from the cluster test suite [1], so their configuration might slightly differ from the standalone mode. [1] http://wiki.eclipse.org/RAP/RWT_Cluster#Test_Infrastructure
(In reply to comment #1) > What servlet engine are you using? We are using jetty 6.1.23 which is embedded in our application, i.e. we do not deploy our application as war file. Thanks for your investigations.
For each standing callback request it is checked regularly (currently every 30 Seconds) whether the request should be released. These checks were extended to also include the session timeout. If a callback request is held for a longer than the session timeout interval, it is released. Changes are in CVS HEAD
