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.
Part of rename functionality is performed in AWT thread, blocking the whole IDE's UI for a long time. Thread dump shows o.n.m.java.JavaParserGlue$2.run() is the culprit.
Please attach thread dump. JavaParserGlue doesn't have direct relation to any refactoring - well - should not have :)
Created attachment 14614 [details] Thread Dump at the moment I clicked "Do Refactoring" for rename.
Fixed. RefireCookieChange was performed in AWT Event Queue. I moved it to RequestProcessor. Checking in JavaParserGlue.java; /cvs/java/src/org/netbeans/modules/java/JavaParserGlue.java,v <-- JavaParserGlue.java new revision: 1.44.20.4; previous revision: 1.44.20.3
The behaviour of the action is not a bit better. Have you tried it after you made the "fix"?
Did you make a thread dump before you reopened your "issue". You reported, that o.n.m.java.JavaParserGlue is blocking AWT Thread. I fixed this issue. Can you attach thread dump showing, that JavaParserGlue is doing that? Problem is, that all files, modified by refactoring, are reparsed at the end of MDR transaction. This is done in separate thread, but JavaEditor is waiting for ExlusiveMutex (held by MDR Thread) in AWT event queue.
This bug is about "Rename action is blocking AWT thread". If you fixed a part of the problem, you should reassign the bug to editor to fix the rest.
Created attachment 15010 [details] Thread dump shows that AWT thread is blocked waiting for a mutex in javacore (via NBMDRepositoryImpl.beginTrans)
Unfortunately I don't have any idea how to fix it. Refactoring is done in Request Processor Thread and holds ExclusiveMutex during it's transaction. Anyone can request ExclusiveMutex while it is held by other transaction and must wait for it. Any help would be appreciated.
Would it be possible to use ReadMutex/WriteMutex technique instead of ExclusiveMutex, allowing owners of ReadMutex to get the old state information until the write transaction is completed (and thus not blocking the readers)? I am not sure if transactional mechanism in MDR would allow such a different approach, but it seems to be the only way to minimize the duration of the state when MDR is totally locked (for readers of the information). Other way would be perhaps minimizing the need of getting information from MDR from other modules than refactoring, which is perhaps unfeasible.
Moved to new subcomponent java/javacore.
Cannot reproduce any more. AWT was blocked by JavaNodes. This issue was already fixed.
Verified in trunk build 200406301800.
Reorganization of java component