Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 343311

Summary: TaskSelectionDialog causes high load
Product: z_Archived Reporter: Benjamin Muskalla <b.muskalla>
Component: MylynAssignee: Benjamin Muskalla <b.muskalla>
Status: CLOSED MOVED QA Contact:
Severity: major    
Priority: P1 CC: shawn.minto, steffen.pingel
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Whiteboard:
Attachments:
Description Flags
thread dump none

Description Benjamin Muskalla CLA 2011-04-19 16:05:12 EDT 
In the last weeks, it occurred many times that my eclipse consumed 200% cpu time with no apparent reason. After seeing this several times with a threaddump, I'm pretty sure this is caused by the TaskSelectionDialog jobs. Note that there are no TaskSelectionDialogs open at the time and the job still runs forever. Seems the job sometimes doesn't get canceled when I close the dialog.

"Worker-7" prio=10 tid=0x08b47c00 nid=0x106e runnable [0x2935c000]
java.lang.Thread.State: RUNNABLE

	at java.util.HashMap.put(HashMap.java:405)
	at java.util.HashSet.add(HashSet.java:200)
	at java.util.AbstractCollection.addAll(AbstractCollection.java:305)
	at org.eclipse.mylyn.internal.tasks.ui.actions.TaskSelectionDialog$TasksFilter.populateTasksFromWorkingSets(TaskSelectionDialog.java:357)
	at org.eclipse.mylyn.internal.tasks.ui.actions.TaskSelectionDialog$TasksFilter.matchItem(TaskSelectionDialog.java:345)
	at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$ContentProvider.add(FilteredItemsSelectionDialog.java:2687)
	at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$FilterJob.filterContent(FilteredItemsSelectionDialog.java:2166)
	at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$FilterJob.internalRun(FilteredItemsSelectionDialog.java:2130)
	at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$FilterJob.doRun(FilteredItemsSelectionDialog.java:2102)
	at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$FilterJob.run(FilteredItemsSelectionDialog.java:2089)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

Locked ownable synchronizers:
- None
Comment 1 Benjamin Muskalla CLA 2011-04-19 16:06:08 EDT 
Created attachment 193616 [details]
thread dump

the thread dump
Comment 2 Steffen Pingel CLA 2011-04-20 10:16:40 EDT 
Do you have any steps how you are typically opening or closing the dialog? From a quick look at the code it appears that listeners are properly removed and the job is being cancelled. Do you have any errors in the log?
Comment 3 Benjamin Muskalla CLA 2011-04-20 10:22:27 EDT 
Nothing in the logs. I remember that sometimes, when I open up the dialog, Mylyn starts indexing (stays first a 0%) and in that moment I cancel the dialog with Escape and search in the task list :P Maybe that's how I manage to get into this state. As said, this happens sometimes, saw it 2-3 times in the last weeks.
Comment 4 Steffen Pingel CLA 2011-04-20 11:16:37 EDT 
And that is the open task dialog? How do you trigger the dialog, through the key-binding?
Comment 5 Benjamin Muskalla CLA 2011-04-20 13:39:16 EDT 
Yup, using "Open Task" and "Activate Task" dialog, always access via keybindings.
Comment 6 Benjamin Muskalla CLA 2011-05-16 06:30:30 EDT 
I think I just got some more infos:

Used the Open Task dialog while the "Synchronize Queres" job was running in the background. Opening the dialog and typing something ended in "Searching in cache (0%)". At this point, no filtering was happening and it was stuck at 0%. At that time, my mylyn consumes endless cycles and I need to restart Eclipse.

Steffen, any good idea how to track this down? Anything I can provide the next time we see this?
Comment 7 Benjamin Muskalla CLA 2011-05-30 04:55:31 EDT 
Happens to me almost every day now. Same as before, Searching in cache is stuck at 0%. Will try to investigate as I'm running Mylyn in debug mode anyway.
Comment 8 Steffen Pingel CLA 2011-07-26 15:06:29 EDT 
Are you still seeing this problem?
Comment 9 Benjamin Muskalla CLA 2011-07-26 17:47:50 EDT 
Didn't happen in the last two weeks (reinstall, currenlty running on OpenJDK). Let me get back to this next week, will run with Sun JDK again to see of the problem persists. If not, we should close this.
Comment 10 Benjamin Muskalla CLA 2011-12-08 17:57:16 EST 
Happened to me once some weeks ago and actually got it into debug mode. The problem was that Hashmap#put ran into an endless loop due to some clashing hashes. Never happend again after that. Will see if I can reproduce in a clean workspace.
Comment 11 Shawn Minto CLA 2012-01-09 13:56:19 EST 
I see this problem as well with Eclipse 3.7.1 and Mylyn HEAD.
Comment 12 Shawn Minto CLA 2012-01-09 13:58:03 EST 
I just noticed that the equals method uses the handle of the task, but the hashcode method uses the task id.  I think that they should both use the handle.  I wonder if this is the root cause of the problem.
Comment 13 Steffen Pingel CLA 2012-01-09 14:21:06 EST 
That might be related. It would be great if we could come up with a test case to reproduce the problem. 

The reason for the weird hashCode() implementation is that the handleIdentifier of tasks can change in the life-cycle of a task and hence the taskId is used. That is pretty bad but also not easy to change without a risk of causing regressions. I'll raise the priority of this bug though since the impact is very noticeable.
Comment 14 Eclipse Webmaster CLA 2022-11-15 11:45:08 EST 
Mylyn has been restructured, and our issue tracking has moved to GitHub [1].

We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub.

[1] https://github.com/orgs/eclipse-mylyn