This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I need to do some cleanup in java module. I selected several modules in Favorites Tab (javacore, src, srcmodel, parser) and tried to delete. After a while IDE hanged, because it was completely overloaded. I need to kill the IDE and do deletion by hand.
Created attachment 48659 [details] Full thread dump
Favorites just calls delete on underlying DataObject as you can see in AWT thread. Passing to loaders for evaluation.
Favorites could run this as background task and not to block AWT thread. But this would not fix primary problem: Why there is so many XmlFoldManager threads and why call stack of Module-Actions thread is so deep adn why it is waiting on lock which is not held elsewhere.
I think, that deep Module-Action thread is OK. It is probably recursive delete of deep directory tree.
I have filed issue 116004 about the TimerTasks. Still, it is suspicious that they were created at all. Did you have opened any xml files (or more specifically tens of them)? In a "show changes" dialog? Or as diffs? The problem with slow deletion is heavily influenced by the fact tha the IDE first recognizes all the files and then deletes them as they wish - i.e. the deletion is performed on the DataObject level with all the whistles.
After looking at profiling output, I suspect the biggest hotspot is localhistory.
Created attachment 49658 [details] Snaphost of delete of my NetBeans 5.5.1 installation
> Did you have opened any xml files (or more specifically tens of them)? In a "show changes" dialog? Or as diffs? I probably had some xml files open, possibly some diffs, but definitely not those, I wanted to delete.
I cannot reproduce the hang, but performance is still horrible. Now I tried to delete ruby project. I lost my patience after 45 minutes. Thread dump shows activity in org.netbeans.spi.java.project.support.ui.PackageView.findNonExcludedPackages(PackageView.java:162) and in org.netbeans.modules.localhistory.utils.FileUtils.copy(FileUtils.java:92) It looks like implementation of delete action is simply not designed for such operations. I'm not able to expand folders in favorites tab (it is immediately collapsed back) and I see flashing progress "finding packages in ...". CPU is at 100%.
the localhistory is copying files into its storage before they get deleted. This takes some time, whether zipping them or not. I've filed a new bug to deal with it (117355), still - there seems to be more in this issue ... - the originally reported hung up - could not reproduce and i also haven't seen anything related to the LH in the attached thread dump. - flashing favorites tab - reassigning for further evaluation.
Ok separate issue for localhistory is filled and marked as blocker for this issue. For unneeded refresh of TreeView I file separate issue against openide/explorer #117422. Not sure if there is anything else besides localhistory issue. If not you can close this issue. Note: tstupka if you change component/subcomponent you should also change owner. As I handle more components I check only issues assigned directly to me. I do not have query with list of ~ 5 IZ components and check all issues in these categories again and again..... Result is that such issue with incorrect owner can lay in IZ looong time without notice......
Two issues are filed, I do not think there is anything to do here anymore.
*** Issue 119351 has been marked as a duplicate of this issue. ***