Community
Participate
Working Groups
I am using Task working sets to group my tasks. This causes all working sets appearing after the last task working set in the working set model to be lost when eclipse isn't shut down cleanly. Steps to reproduce: - Create a Resource working set A - Create a Task working set B - Create another Resource working set C - Take a look at .metadata/.plugins/org.eclipse.ui.workbench/workingsets.xml - the order of the working sets in there should be A, B, C - Restart eclipse - Kill eclipse hard without touching the working sets - Restart eclipse - Working Set C is gone The cause of this is the following: On startup, while the WorkingSetManager is still in the process of loading the working sets from file, the Mylyn TaskWorkingSetUpdater triggers a save of the WorkingSetManager for every freshly loaded Task working set (see stack trace below). Since not all WorkingSets have been loaded at that point, after we are through with loading we end up with a persisted configuration including only the sets up to the last Task WorkingSet. Now, this is usually not a problem if eclipse can be closed cleanly, which triggers a save of the complete model. However, when eclipse freezes (as it is prone to do especially during startup) and has to be shut down hard, you end up with the incomplete model persisted at that point on next startup. Thread [Thread-3] (Suspended (entry into method saveWorkingSetState in AbstractWorkingSetManager)) owns: HashMap<K,V> (id=84) WorkingSetManager(AbstractWorkingSetManager).saveWorkingSetState(IMemento) line: 453 WorkingSetManager(AbstractWorkingSetManager).saveState(File) line: 810 WorkingSetManager.saveState() line: 136 WorkingSetManager.workingSetChanged(IWorkingSet, String, Object) line: 158 WorkingSet(AbstractWorkingSet).fireWorkingSetChanged(String, Object) line: 132 WorkingSet.setElements(IAdaptable[]) line: 242 TaskWorkingSetUpdater.checkElementExistence(IWorkingSet) line: 130 TaskWorkingSetUpdater.add(IWorkingSet) line: 105 AbstractWorkingSetManager$12.run() line: 740 SafeRunner.run(ISafeRunnable) line: 42 WorkingSetManager(AbstractWorkingSetManager).addToUpdater(IWorkingSet) line: 736 WorkingSetManager(AbstractWorkingSetManager).internalAddWorkingSet(IWorkingSet) line: 242 WorkingSetManager(AbstractWorkingSetManager).restoreWorkingSetState(IMemento) line: 513 WorkingSetManager.restoreState() line: 109 WorkbenchPlugin.getWorkingSetManager() line: 609 Workbench.getWorkingSetManager() line: 1455 WorkbenchPage.restoreState(IMemento, IPerspectiveDescriptor) line: 3165 WorkbenchWindow.restoreState(IMemento, IPerspectiveDescriptor) line: 2219 Workbench.doRestoreState(IMemento, MultiStatus) line: 3612 Workbench.access$29(Workbench, IMemento, MultiStatus) line: 3554 Workbench$55.run() line: 2261 Workbench.runStartupWithProgress(int, Runnable) line: 1975 Workbench.restoreState(IMemento) line: 2259 Workbench.access$27(Workbench, IMemento) line: 2230 Workbench$50.run() line: 2093 SafeRunner.run(ISafeRunnable) line: 42 Workbench.restoreState() line: 2037 WorkbenchConfigurer.restoreState() line: 183 WorkbenchAdvisor$1.run() line: 781
Created attachment 180443 [details] Fix for TaskWorkingSetUpdater triggering a save This patch makes the TaskWorkingSetUpdater avoid an unnecessary save on the workingset model if it didn't change anything. This seems to be working for the other implementations of IWorkingSetUpdater, althought theoretically, the problem could still occur if for some reason there were entries to be removed during startup.
Thanks for the great description and patch! This has been a long standing problem and we never got to the bottom of it. I'll merge this shortly. If understand correctly, it sounds like this is actually a problem in the platform and that saving of working sets during loading should be prevented or delayed to avoid saving partial state?
Yes, that's right. Saving during load is pretty dangerous, because it is almost guaranteed to persist a partial state. Usually, no change should be made to a WorkingSet during load I guess, which is what my patch fixes for the task sets. But when that occurs, it would be good if the platform would handle that situation gracefully. One way to do that is to disable save during load and if there are save requests to save the whole model after loading. A more dirty solution would be to always trigger a save after the model was fully loaded...
Created attachment 180554 [details] additional change to avoid loading of working sets during shutdown
Created attachment 180555 [details] mylyn/context/zip
Committed both patch to head and e_3_6_m_3_4_x branch. Thanks a lot for the fix, Carsten!
