Community
Participate
Working Groups
I don't know exactly what I did, but suddenly I have a job called "Resolve filter stings (RSE Subsystem Operation:)" that does not want to end. Cancel did not help. Other RSE job (even on other subsystems) are waiting. A wait cursor is showed on all views. See: http://scharf.gr/eclipse/rse/problems/blocking-job/
Created attachment 51592 [details] Thread dump of the blocking non cancelable job Thread dump of the blocking non cancelable job
This looks dangerous to me in SubSystem.scheduleJob: while (!job.hasStarted()) { while (display!=null && display.readAndDispatch()) { //Process everything on event queue } if (!job.hasStarted()) Thread.sleep(200); } Because job.hasStarted() seems not to deal with cancellation... I also think it is dangerous to have a secondary event loop here. I would not be surprised if this is the cause of many threading and UI blocking related bugs. SubSystem.scheduleJob is called from the main thread (the UI thread) and is essentially blocking! The idea of jobs is to run in parallel to the UI thread and *not* to block the UI thread. We had some severe problems in our products with secondary event loops. They are *very* bad... Now I also understand the deep stack-trace of bug 160084
In the stack provided, the main thread uses SubSystem.scheduleJob(). That approach is a hack to be used in the old way of RSE queries - where deferred queries were not supported (there's a preference for this). The SystemTableTreeView (the one the monitor view uses) was still using the old approach to get at children, which is problemmatic. I've added support for deferred queries to that view now so that we avoid the main thread scheduleJob problem. I know that this won't address all cases of scheduleJob() but at least it will deal with the case described in the stack. I'll leave this open so that it can be used on other problemmatic scheduleJob() scenarios if they're encountered.
This should be fixed now. All resolveFilterStrings methods that are called directly on main thread should no longer be using jobs. Also, I've taken out the readAndDispatch() that is used in the DStoreStatusMonitor - in normal cases, the waitForUpdate() should not be called on the main thread anyway. SubSystem.scheduleJob still exists although the important cases should be avoiding it now (disconnect, connect and the resolveFilterStrings methods). Reopen if these scenarios continue to occur with the fix.
[target cleanup] 1.0 RC2 was the original target milestone for this bug
