Community
Participate
Working Groups
I think this error screw the job scheduling real bad. -- Error Log -- Date: Wed Aug 30 11:45:31 EDT 2006 Message: Failed to execute runnable (java.util.ConcurrentModificationException) Severity: Error Plugin ID: org.eclipse.ui Stack Trace: org.eclipse.swt.SWTException: Failed to execute runnable (java.util.ConcurrentModificationException) at org.eclipse.swt.SWT.error(SWT.java:3374) at org.eclipse.swt.SWT.error(SWT.java:3297) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:126) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3325) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2971) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177) 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.core.launcher.Main.invokeFramework(Main.java:336) at org.eclipse.core.launcher.Main.basicRun(Main.java:280) at org.eclipse.core.launcher.Main.run(Main.java:977) at org.eclipse.core.launcher.Main.main(Main.java:952) Caused by: java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793) at java.util.HashMap$KeyIterator.next(HashMap.java:827) at org.eclipse.mylar.tasks.core.TaskList.findQueryHitHelper(TaskList.java:284) at org.eclipse.mylar.tasks.core.TaskList.getQueryHitsForHandle(TaskList.java:502) at org.eclipse.mylar.internal.tasks.ui.views.TaskListContentProvider.getFilteredChildrenFor(TaskListContentProvider.java:201) at org.eclipse.mylar.internal.tasks.ui.views.TaskListContentProvider.getChildren(TaskListContentProvider.java:73) at org.eclipse.jface.viewers.AbstractTreeViewer.getRawChildren(AbstractTreeViewer.java:1157) at org.eclipse.jface.viewers.TreeViewer.getRawChildren(TreeViewer.java:768) at org.eclipse.jface.viewers.AbstractTreeViewer.getFilteredChildren(AbstractTreeViewer.java:565) at org.eclipse.jface.viewers.AbstractTreeViewer.getSortedChildren(AbstractTreeViewer.java:534) at org.eclipse.jface.viewers.AbstractTreeViewer.updateChildren(AbstractTreeViewer.java:2326) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefreshStruct(AbstractTreeViewer.java:1640) at org.eclipse.jface.viewers.TreeViewer.internalRefreshStruct(TreeViewer.java:955) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1616) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1571) at org.eclipse.jface.viewers.StructuredViewer$8.run(StructuredViewer.java:1415) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1323) at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1413) at org.eclipse.mylar.internal.tasks.ui.views.TaskListView$11.run(TaskListView.java:1518) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123) ... 20 more
It seems like this issue trigger something bad inside eclipse, so many actions just stop working while there is some background processing going on. I guess it could be somehow related to the state of ui thread. I looked at the code and it seems to me that the way AbstractRepositoryQuery is dealing with "hits" field is completely broken. All access to hits field in this class is non synchronized and then method getHits(), "hits" is wrapped into the new instance of the synchronized collection on every call. So, all synchronization on that returned value will have no effect because it will be synchronizing on new instance every time: public Set<AbstractQueryHit> getHits() { return Collections.synchronizedSet(hits); } But this is not all! Users of getHits() methods doing stuff like this (e.g. JiraTaskExternalizer): Set<AbstractQueryHit> hits = Collections.synchronizedSet(query.getHits()); synchronized (hits) { for (AbstractQueryHit hit : hits) { .... I also noticed quite inefficient use of getHits() method in label providers and decorators... I don't even know where to start refactoring this mess. :-)
Created attachment 49237 [details] patch that should fix concurrency issue I've added consistent synchronization on method of the AbstractRepositoryQuery that are working with hits collection and updated other classes that were using this. getHits() now always creates copy wich can be iterated safely. It is possible that other Mylar componants may have similar issues...
Created attachment 49238 [details] mylar/context/zip
Great contribution Eugene, it's about time that this bogus approach to synchronizations that we hacked in way back got fixed...
Patch applied.
*** Bug 154895 has been marked as a duplicate of this bug. ***
