Bugzilla – Full Text Bug Listing
| Summary: | Exception when SessionStoreListener is called: java.lang.IllegalStateException: The session store is about to be unbound | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [RT] RAP | Reporter: | Ryan Donnelly <ryanrd1> | ||||
| Component: | RWT | Assignee: | Project Inbox <rap-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P2 | CC: | rsternberg, ruediger.herrmann | ||||
| Version: | 1.2 | Flags: | rsternberg:
review+
|
||||
| Target Milestone: | 1.2 RC3 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Created attachment 137561 [details]
Proposed patch to fix the problem
+1 Committed patch to CVS HEAD Thanks for the fix. I have rebuilt my application against RAP CVS and no longer get either exception. Unfortunately, my memory leak problem remains (news://news.eclipse.org:119/guficg$rn5$1@build.eclipse.org). I will attempt to create a code snippet that can reproduce the problem, but are there any other open issues that you think could be involved in the memory leak? (In reply to comment #4) > [ ... ] > I will attempt to create a code snippet that can reproduce the problem, but are there any other open issues that you > think could be involved in the memory leak? There are two possible leaks when Jobs are involved (bug 274017 and bug 274021) but if I recall correctly, you aren't using the Jobs API. Apart from that, there are no known memory leaks. |
Build ID: M20090211-1700 Steps To Reproduce: We have a complicated RAP application, single-sourced SWT/RWT starting from our original SWT application, running in Tomcat 6.0.18 on Windows XP, RAP 1.2 M7 (in fact I've also tried RAP built from the latest RAP CVS from Thu 14 May), the basic structure of which I have sketched below. public int createUI() { final String httpSessionId = RWT.getSessionStore().getId(); UICallBack.activate(httpSessionId); RWT.getSessionStore().addSessionStoreListener(new SessionStoreListener() { public void beforeDestroy(SessionStoreEvent event) { if not already disposed { ...dispose shells, close db connection, etc.... } final String httpSessionId = event.getSessionStore().getId(); UICallBack.deactivate(httpSessionId); } }); ...open shells, db connection, etc.... ...read and dispatch loop... ...dispose shells, close db connection, etc.... RWT.getRequest().getSession().setMaxInactiveInterval(1); return 0; } When the SessionStoreListener is entered, an exception appears in Tomcat's localhost.XXX.log, same as in the following old resolved bug: #216094 Frequently java.lang.IllegalStateException: The session store is about to be unbound https://bugs.eclipse.org/bugs/show_bug.cgi?id=216094 When exiting through the normal path (i.e. createUI returns), when my 1s timeout expires and the SessionStoreListener is entered (this actually takes up to 1 minute to be entered, I assume because of Tomcat): May 15, 2009 5:02:14 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet equinoxbridgeservlet threw exception java.lang.IllegalStateException: The session store is about to be unbound. at org.eclipse.rwt.internal.service.SessionStoreImpl.checkAboutUnbound(SessionStoreImpl.java:251) at org.eclipse.rwt.internal.service.SessionStoreImpl.removeSessionStoreListener(SessionStoreImpl.java:125) at org.eclipse.rwt.internal.lifecycle.UICallBackManager.blockCallBackRequest(UICallBackManager.java:214) at org.eclipse.rwt.internal.lifecycle.UICallBackServiceHandler.service(UICallBackServiceHandler.java:418) at org.eclipse.rwt.internal.service.ServiceManager$HandlerDispatcher.service(ServiceManager.java:99) at org.eclipse.rwt.internal.engine.RWTDelegate.doPost(RWTDelegate.java:63) at org.eclipse.rap.ui.internal.servlet.RequestHandler.service(RequestHandler.java:51) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.eclipse.equinox.http.servlet.internal.ServletRegistration.handleRequest(ServletRegistration.java:90) at org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:111) at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:59) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.eclipse.equinox.servletbridge.BridgeServlet.service(BridgeServlet.java:120) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:857) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:565) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1509) at java.lang.Thread.run(Unknown Source) I also notice the error when exiting through an abnormal path, in this case F5 (Refresh) on the browser, so that createUI() never returns and the session is re-opened. The error I get, also, I assume, when the SessionStoreListener is entered, is the above error or the similar: May 15, 2009 5:14:55 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet equinoxbridgeservlet threw exception java.lang.IllegalStateException: The session store has been unbound. at org.eclipse.rwt.internal.service.SessionStoreImpl.checkBound(SessionStoreImpl.java:244) at org.eclipse.rwt.internal.service.SessionStoreImpl.removeSessionStoreListener(SessionStoreImpl.java:126) at org.eclipse.rwt.internal.lifecycle.UICallBackManager.blockCallBackRequest(UICallBackManager.java:214) at org.eclipse.rwt.internal.lifecycle.UICallBackServiceHandler.service(UICallBackServiceHandler.java:418) at org.eclipse.rwt.internal.service.ServiceManager$HandlerDispatcher.service(ServiceManager.java:99) at org.eclipse.rwt.internal.engine.RWTDelegate.doPost(RWTDelegate.java:63) at org.eclipse.rap.ui.internal.servlet.RequestHandler.service(RequestHandler.java:51) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.eclipse.equinox.http.servlet.internal.ServletRegistration.handleRequest(ServletRegistration.java:90) at org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:111) at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:59) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.eclipse.equinox.servletbridge.BridgeServlet.service(BridgeServlet.java:120) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:857) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:565) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1509) at java.lang.Thread.run(Unknown Source) Rüdiger Hermann suggests in our discussion in the newsgroup news://news.eclipse.org:119/gurgsa$qqv$1@build.eclipse.org "these exceptions shouldn't happen and likely prevent proper clean up." More information: