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.
Build: NetBeans IDE 6.9 (Build 201006101454) VM: Java HotSpot(TM) 64-Bit Server VM, 16.3-b01, Java(TM) SE Runtime Environment, 1.6.0_20-b02 OS: Windows 7 User Comments: GUEST: Debugging TransferHandler class. Maximum slowness yet reported was 62401 ms, average is 41364
Created attachment 101540 [details] nps snapshot
JavaSource.runWhenScanFinished() is supposed to run asynchronously, but it blocks for 52 second.
(In reply to comment #2) > JavaSource.runWhenScanFinished() is supposed to run asynchronously, but it > blocks for 52 second. Sorry, but this is not how the rSCF is documented to behave (and I don't think it ever was supposed to behave that way). It runs asynchronously if and only if a background scan is running, and is running synchronously otherwise. In the case of: http://statistics.netbeans.org/exceptions/exception.do?id=600318 (which is currently the most recent report), the debugger itself is holding the parsing lock (Debugger Context Scanning), preventing the AWT from entering it.
I saw 26s delay. Other report says 62s. That would justify higher priority than P3.
Fixed by changeset: 233021:685c7aa4c03e http://hg.netbeans.org/main/rev/685c7aa4c03e
Integrated into 'main-golden', will be available in build *201209190001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/685c7aa4c03e User: mentlicher@netbeans.org Log: #189695: Assure that AWT is not blocked by source scanning.
Since this has 120+ duplicates, let's integrate this bug fix to NetBeans 7.2.2.
Product Version: NetBeans IDE Dev (Build 201210040002) Updates: Updates available Java: 1.7.0_06; Java HotSpot(TM) Client VM 23.2-b09 System: Linux version 3.0.0-12-generic running on i386; UTF-8; cs_CZ (nb) User directory: /home/cesilko/.netbeans/dev Cache directory: /home/cesilko/.cache/netbeans/dev I tried to reproduce the slowness in today's trunk build on a simple Java application with ~20 preset breakpoints and also while debugging a class testing NetBeans debugger. No slowness occurred hence I consider the bug as verified.
The slowness NetBeans detected was [probably] due to my source mounted on an nfs mounted network storage location.
Our home directories are on a NFS mount. It's not something I have a choice in. The bank configures the machine this way. This causes NB to locks up at times, Eclipse seems to handle the same conditions better as many developers have voted with their feet.
Nigel & Bryan, you probably mean that even with the fix it is still slow in the latest development build, am I right?
Martin, can you please integrate the fix to release72 branch and update the status whiteboard? Thanks!
Pushed as changeset: 242846:180ddde8263c http://hg.netbeans.org/releases/rev/180ddde8263c
Integrated into 'releases', will be available in build *201210100934* or newer. Wait for official and publicly available build. Changeset: http://hg.netbeans.org/releases/rev/180ddde8263c User: mentlicher@netbeans.org Log: #189695: Assure that AWT is not blocked by source scanning. (transplanted from 685c7aa4c03e1e3e37ee615f6a5436d60d6627db)
I meant that this slowness (for me) could have been due to scanning source mounted on an nfs share, when our network was experiencing high traffic.
I tried to reproduce this in NetBeans 7.2.2 build #201210100934 but encountered bug #219900 instead. Since it was not tagged as duplicate of this bug I am verifying this and leaving #219900 opened for further investigation.