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.
When I switch the editor to another Java source code file (already opened on a different tab), the IDE's GUI is blocked until the file is parsed and the Navigator window's content updated. I am attaching a full thread dump. I made it with jstack while source code of javax.swing.JTable (of JDK 6u13) was being opened. -- NetBeans 6.7 development build 090507 JDK 6u14-ea-b05, 64-bit, server VM Linux (Debian Lenny), 64-bit, Intel CPU
Created attachment 81909 [details] full thread dump (opening source code of JTable)
I am not sure whether this is a bug in the platform or in one of the Java-related modules. Please reassign as appropriate.
*** Issue 164938 has been marked as a duplicate of this issue. ***
*** Issue 159633 has been marked as a duplicate of this issue. ***
*** Issue 165142 has been marked as a duplicate of this issue. ***
To reproduce, it is necessary to have enabled "Show inherited members". A fix is in jet-main cbe5f32861cd.
Integrated into 'main-golden', will be available in build *200905141401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/cbe5f32861cd User: Jan Lahoda <jlahoda@netbeans.org> Log: #164874: compute the FileObject for ElementNode's lookup lazily.
This issue seems not to be resolved, because the effect, marian describes herein, occures also with Netbeans 7.3 @ JDK 1.7.0_21-b12 @ Mac OS X 10.8.3 (12D78) Sometimes, the IDE is blocked for about 20s and above and the Netbean's "Blocked IDE recognition" dialog appears. Please fix this issue, due to it is a real life blocker! thx. alot, Robert
rherschke: its unlikely that whatever you are seeing is the same as what is reported in this three years old bug, and your comment is not providing enough information to evaluate the problem. Please file a new bug with a thread dump and all other information that you can provide, so it can be properly evaluated. Thanks.
So? It is the same strange behavior! What should I describe more than Marian's first comment? It is the very same result, the IDE is behaving. Ok. With this approach, it's unlikely that Netbeans will be perceived as a real competitor to other IDE's. Robert.
(In reply to comment #10) > So? It is the same strange behavior! What should I describe more than Marian's > first comment? It is the very same result, the IDE is behaving. Sorry, but I am not sure what to do here - OK, the behaviour is the same, but is the root cause the same? I doubt that, but there is really no way to find out, as there is neither new thread dump nor new profiler snapshot, etc. And without knowing what is the actual problem, I don't really know what to fix. > > Ok. With this approach, it's unlikely that Netbeans will be perceived as a real Sorry, but all that I asked is to file a new bug with the details needed to find out the root cause. If that is too difficult, please at least attach the needed information (i.e. either a thread dump when the hand happens, or a self-profiler snapshot) to this bug, and I can file the new bug myself as appropriate. > competitor to other IDE's. > > Robert.
ok. agreed. if the next "Blocking IDE detection" is shown up, I will file a new bug.
(In reply to comment #12) > ok. agreed. > if the next "Blocking IDE detection" is shown up, I will file a new bug. Thanks. If the popup actually appears, it should be possible to simply submit the report. It should show a URL after it is submitted - if you could paste it here, it would help limit the risk of loosing the report. Thanks.
see issue: http://statistics.netbeans.org/analytics/exception.do?id=675770
Thanks for the link. The primary assignment for the bug (the report leads to bugzilla bug #225364, which is JMX) is correct - the JMX support is trying to get the Java lock in AWT, but that lock provides no real-time guarantees and should not be taken in AWT. But, in this case, the lock is held by the FindBugs support, which was not cancelled properly. That is a known bug fixed some time ago, but the fix is unlikely to be available on the stable update centers before NetBeans 7.4, and is unlikely to be available for previous versions. To alleviate the situation, I would suggest to: 1. Install updated version of the FindBugs integration from here: http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/lastSuccessfulBuild/artifact/nbbuild/nbms/extra/org-netbeans-modules-findbugs.nbm (download and then do Tools/Plugins/Downloaded) 2. If that does not not improve the situation enough, either disable the JMX plugin, or disable running FindBugs inside editor (Tools/Options/Editor/Hints/Language=FindBugs/Run FindBugs in Editor).
Wow, thanks for the detailed report. I have switched of Findbugs and JMX and now Netbeans is as fast as usual. While trying the given nbm update, although looking forward to 7.4... (can't await...) Regards, Robert