Community
Participate
Working Groups
I'm finding that when I restart Eclipse after a crash and I had an active task, that mylyn has forgotten about files that I've been working with before the crash. Some appear in the context, but are not automatically re-opened, while othere are just not there.
This has happened to me as well. Contexts are only saved on task deactivation. Rob, is there another bug that tracks more frequent saving of contexts?
I don't think that we have another bug for this. Should we implement a save policy, e.g. auto-save every 30 or 60 seconds when active?
+1 if the the auto-save job can be "smart", i.e. not save the context if there haven't been any changes
I think the context should also be updated when a "resource" is added or removed.
That seems like a great approach. We could trigger a save after every n'th interaction event processed. Similar to what Steffen told me today about Emacs (does saves on every 200th character event processed).
Rob, assigning to you since this is related to scheduling save jobs and resource locking.
*** Bug 235860 has been marked as a duplicate of this bug. ***
Unfortunately this will not get completed for 3.1. We'll investigate extraction of context externalization code for 3.1.
We may need to give this its own timer if we can't easily generalize the externalization framework.
Created attachment 148471 [details] patch Here is the first cut at a patch that will autosave the active context every 3-5 minutes if the user is active, or when they become inactive. I had to add in a way to collapse and copy the context so that it could be externalized asynchronously. Steffen, could you take a look at this to make sure I didn't miss any weird synchronization issues that I should deal with, or if you have any suggestions on how this could be improved?
Created attachment 148472 [details] mylyn/context/zip
The patch looks good to me. A few comments: Can you add a few comments to ActiveContextExternalizationParticipant? We need to document that it is only responsible for saving periodically and everything else is handled by InteractionContextManager. Why are these null checks ContextCorePlugin.getDefault() and MonitorUiPlugin.getDefault() necessary? ActiveContextExternalizationParticipant.shouldWriteContext() does not seem to be fully implemented. Can't you simply add a version field to InteractionContext that is incremented each time there is a change? Why is the entire LocalContextStore.saveContext() method synchronized? That seems unnecessary and dangerous since it calls out to other classes while holding the lock. Can't we limit the lock to the actual copying and persisting of the context? What I find weird in the context architecture is that DegreeOfInterest holds on to events. Shouldn't storing those be be limited to InteractionContext?
> Can you add a few comments to ActiveContextExternalizationParticipant? We need > to document that it is only responsible for saving periodically and everything > else is handled by InteractionContextManager. Done. > Why are these null checks ContextCorePlugin.getDefault() and > MonitorUiPlugin.getDefault() necessary? I dont think that they are necessary. > ActiveContextExternalizationParticipant.shouldWriteContext() does not seem to > be fully implemented. Can't you simply add a version field to > InteractionContext that is incremented each time there is a change? Good catch on the TODO. It is only there since it could be nice, but the context is only written if the user is active, which in general would mean that the context has changed. > Why is the entire LocalContextStore.saveContext() method synchronized? That > seems unnecessary and dangerous since it calls out to other classes while > holding the lock. Can't we limit the lock to the actual copying and persisting > of the context? I moved the synchronized block to be just around the copying and writing. > What I find weird in the context architecture is that DegreeOfInterest holds on > to events. Shouldn't storing those be be limited to InteractionContext? Probably. I will create a new bug for this.
Created attachment 149061 [details] mylyn/context/zip
Created attachment 149062 [details] updated patch with steffens comments Patch committed.
I am getting this exception in my log on startup: java.lang.Exception at org.eclipse.mylyn.internal.tasks.ui.ActiveContextExternalizationParticipant.registerListeners(ActiveContextExternalizationParticipant.java:82) at org.eclipse.mylyn.internal.tasks.ui.TasksUiPlugin$TasksUiInitializationJob.runInUIThread(TasksUiPlugin.java:443) at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:95) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3468) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3115) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2405) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2221) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514) at org.eclipse.equinox.launcher.Main.run(Main.java:1311) at org.eclipse.equinox.launcher.Main.main(Main.java:1287)
It looks like the fix on bug 291237 has fixed this exception. I don't remember why I had this logging in there, should I just remove it?
Yes, we should be able to remove the check now.
I have removed the check now.
