Bugzilla – Full Text Bug Listing
| Summary: | Session reaper may wait forever when UIThread#terminateThread is called | ||
|---|---|---|---|
| Product: | [RT] RAP | Reporter: | Clemens Schneider <hula.bula> |
| Component: | RWT | Assignee: | Project Inbox <rap-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | P3 | CC: | chris, ezanaga, ivan, jens.borrmann, stefanescu.a |
| Version: | 1.5 | ||
| Target Milestone: | 1.5 M3 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Clemens Schneider
Changed version to 1.5, as the source in UIThread did not change compared to 1.3 (In reply to comment #0) > Without further investigation: Shouldn't UIThread#terminateThread() first try to > obtain a lock (UIThread#getLock()) and when in possession of the lock then > interrupt the thread? This sounds reasonable. I changed the code as suggested. The changes will be available in builds >= 2011-10-15. Would you be able to give it a try and report back here if the issue is gone? We stumbled upon this issue, too, when performing some elementary stress tests with our application using a 1.4.0 version. We backported the patch and did not face the problem since then. Since the suggested fix seems to have cured the problem, I'll close this bug. Please reopen if you observe the problem again. The UIThread dlock still occurs. A worker thread and the session scavange got stuck. #################################################################################### Name: HashSessionScavenger-1 #################################################################################### State: WAITING on org.eclipse.rwt.internal.lifecycle.UIThread@238836bb Total blocked: 28 Total waited: 5.200 Stack trace: java.lang.Object.wait(Native Method) java.lang.Thread.join(Unknown Source) java.lang.Thread.join(Unknown Source) org.eclipse.rwt.internal.lifecycle.UIThread.terminateThread(UIThread.java:119) org.eclipse.rwt.internal.lifecycle.UIThread.interceptShutdown(UIThread.java:149) org.eclipse.rwt.internal.service.SessionStoreImpl.valueUnbound(SessionStoreImpl.java:182) org.eclipse.jetty.server.session.AbstractSession.unbindValue(AbstractSession.java:489) org.eclipse.jetty.server.session.AbstractSession.clearAttributes(AbstractSession.java:340) org.eclipse.jetty.server.session.AbstractSession.doInvalidate(AbstractSession.java:307) org.eclipse.jetty.server.session.HashedSession.doInvalidate(HashedSession.java:72) org.eclipse.jetty.server.session.AbstractSession.timeout(AbstractSession.java:285) - locked org.eclipse.jetty.server.session.HashedSession@6e018d18 org.eclipse.jetty.server.session.HashSessionManager.scavenge(HashSessionManager.java:309) org.eclipse.jetty.server.session.HashSessionManager$2.run(HashSessionManager.java:274) java.util.TimerThread.mainLoop(Unknown Source) java.util.TimerThread.run(Unknown Source) #################################################################################### Name: UIThread [1u0sc3difmbpn1g5wi4npliyyb] #################################################################################### State: WAITING on org.eclipse.rwt.internal.lifecycle.UIThread@238836bb Total blocked: 66 Total waited: 1.112 Stack trace: java.lang.Object.wait(Native Method) java.lang.Object.wait(Object.java:485) org.eclipse.rwt.internal.lifecycle.UIThread.switchThread(UIThread.java:59) org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.sleep(RWTLifeCycle.java:232) org.eclipse.swt.widgets.Display.sleep(Display.java:1176) org.eclipse.ui.application.WorkbenchAdvisor.eventLoopIdle(WorkbenchAdvisor.java:361) org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2734) org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2694) org.eclipse.ui.internal.Workbench.access$5(Workbench.java:2530) org.eclipse.ui.internal.Workbench$5.run(Workbench.java:702) org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:685) org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:157) com.atoss.atc.web.core.Application.createUI(Application.java:58) org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.createUI(RWTLifeCycle.java:177) org.eclipse.rwt.internal.lifecycle.RWTLifeCycle$UIThreadController.run(RWTLifeCycle.java:289) java.lang.Thread.run(Unknown Source) org.eclipse.rwt.internal.lifecycle.UIThread.run(UIThread.java:102) I can't set the bug on REOPEN I would say the problem is the "lock object". In this case the actual Thread instance is used as lock object. Then the Thread.join() also tries to get a lock on the tread instance/lock object. I would say if terminateThread() is stopped between interrupt() and join() and the worker thread ends up again in switchThread() it will go on "wait" and nobody notifies it while the Thread on terminateThread() method waits to get a lock on the thread instance. In the meantime the scavenger thread blocks all access to the session object with "AbstractSession.doInvalidate" The fix would be to have a separated "lock" in the place of "this" #################################################################################### Name: New I/O client worker #88-1 #################################################################################### State: BLOCKED on org.eclipse.jetty.server.session.HashedSession@6e018d18 owned by: HashSessionScavenger-1 Total blocked: 5.693 Total waited: 0 Stack trace: org.eclipse.jetty.server.session.AbstractSession.setAttribute(AbstractSession.java:408) org.eclipse.equinox.http.servlet.internal.HttpSessionAdaptor.setAttribute(HttpSessionAdaptor.java:96) org.eclipse.rap.rwt.osgi.internal.HttpSessionWrapper.setAttribute(HttpSessionWrapper.java:78) .....RAPConnectionObserver.connectionLost(RAPConnectionObserver.java:32) (In reply to comment #6) > I can't set the bug on REOPEN As this is an old bug related to RAP 1.4, please create a separate bug and provide your findings there. Which RAP version is affected? |