Community
Participate
Working Groups
If you select a lot of objects (7000 in my case) and restart the workbench we try to restore the selection and this causes the UI to freeze for a good 20 mins. If I pause the main thread I see this: Thread [main] (Suspended) owns: RunnableLock (id=91) OS.SendMessageW(int, int, int, int) line: not available [native method] [local variables unavailable] OS.SendMessage(int, int, int, int) line: 3011 Tree.getItems(int) line: 3241 TreeItem.getItems() line: 787 SystemView(TreeViewer).getChildren(Widget) line: 162 SystemView(SafeTreeViewer).getChildren(Widget) line: 135 SystemView.recursiveFindFirstRemoteItemReference(Item, String, Object, ISubSystem) line: 4823 SystemView.findFirstRemoteItemReference(String, ISubSystem, Item) line: 4480 SystemView.selectRemoteObjects(Object, ISubSystem, Item) line: 3634 SystemView.selectRemoteObjects(Object, ISubSystem, Object) line: 3600 SystemView$ResourceChangedJob.runInUIThread(IProgressMonitor) line: 2416 UIJob$1.run() line: 94 RunnableLock.run() line: 35 UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133 Display.runAsyncMessages(boolean) line: 3800 Display.readAndDispatch() line: 3425 Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 2382 Workbench.runUI() line: 2346 Workbench.access$4(Workbench) line: 2198 Workbench$5.run() line: 493 Realm.runWithDefault(Realm, Runnable) line: 288 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 488 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149 IDEApplication.start(IApplicationContext) line: 113 EclipseAppHandle.run(Object) line: 193 EclipseAppLauncher.runApplication(Object) line: 110 EclipseAppLauncher.start(Object) line: 79 EclipseStarter.run(Object) line: 382 EclipseStarter.run(String[], Runnable) line: 179 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 45 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 Method.invoke(Object, Object...) line: 612 Main.invokeFramework(String[], URL[]) line: 549 Main.basicRun(String[]) line: 504 Main.run(String[]) line: 1236 Main.main(String[]) line: 1212
Sounds bad ... is there a workaround for users to get out of the "hanging mode" again, or does it occur again in case Eclipse is forcefully quit and restarted? Is there a low-risk fix? What's the reason for the performance hit? What about restoring the first item of the entire selection only on restart?
I was stuck in the loop. Forcing closed and reopened it did the same thing again. Twice when in debug mode my mouse even froze. I had to tab around and Terminate Eclipse to get mouse control back. Not sure why this happened and can't make it happen every time.
I consider this critical since there is no easy workaround for users when they get trapped in this -- their whole Eclipse IDE gets unusable. I'd like to shoot for a fix in 3.1 M2 (Oct1) and then see if we can retrofit the fix into 3.0.x
Created attachment 113299 [details] patch limiting the number of selected items on restore to 100 This patch limits the number of selected items on restore to 100. I'm not sure whether this is ideal or whether a more appropriate number could be used. Any thoughts on this approach?
I'm not sure what the "reselect on restart" feature is used for in IBM products, but given that selections are typically of rather transient nature, I'd assume that even selecting a single item only on restart is sufficient. I'd think that even selecting 100 items might be a problem already on slow connections, since it does getRemoteObject() 100 times. And, since the loop performs individual calls, it looks like not even the IFileServcie#getFileMultiple() optimization can be leveraged here... See also bug 248331 which I found today, that's related to problems during restoring expand state and selection on re-start of Eclipse.
(In reply to comment #5) > I'm not sure what the "reselect on restart" feature is used for in IBM > products, but given that selections are typically of rather transient nature, > I'd assume that even selecting a single item only on restart is sufficient. > > I'd think that even selecting 100 items might be a problem already on slow > connections, since it does getRemoteObject() 100 times. > So are you okay with we make the maximum selected items equal 0?
I think it makes sense to preserve a single selected item across quit / restart. I'd actually suggest to also store only one selected item when quitting RSE -- it makes no sense to store 7000 items when only one is about to be used on restart.
Created attachment 113457 [details] patch to only store one selected item on shutdown This patch just stores a max of one selected item.
I've committed the patch to cvs.
I think you'll want restrict reading of the memento to 1 element maximum as well, since we released 3.0 with code that could write lots of selections. So, the 3.0.1 code might get into a situation where it's getting asked to restore 7000 selections.
