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 Dev (Build 20130528-a3efd58900c1) VM: Java HotSpot(TM) Client VM, 23.21-b01, Java(TM) SE Runtime Environment, 1.7.0_21-b11 OS: Linux User Comments: jglick: Senseless scanning; I had not recently changed any public signatures. GUEST: please ignore GUEST: Please ignore Stacktrace: org.netbeans.modules.parsing.impl.indexing.ScanCancelledException: Slow scanning in java at java.lang.Thread.getStackTrace(Thread.java:1567) at org.netbeans.modules.parsing.impl.indexing.LogContext.create(LogContext.java:131) at org.netbeans.modules.parsing.impl.indexing.LogContext.create(LogContext.java:124) at org.netbeans.modules.parsing.api.indexing.IndexingManager.addIndexingJob(IndexingManager.java:443) at org.netbeans.modules.parsing.api.indexing.IndexingManager.refreshIndex(IndexingManager.java:181) at org.netbeans.modules.java.source.tasklist.IncorrectErrorBadges.run(IncorrectErrorBadges.java:172)
Created attachment 135015 [details] stacktrace
Right, you haven't changed public signature but you have opened a file with have no errors when parsed but have error badges or vice versa as seen from the stack trace: at org.netbeans.modules.parsing.api.indexing.IndexingManager.refreshIndex(IndexingManager.java:181) at org.netbeans.modules.java.source.tasklist.IncorrectErrorBadges.run(IncorrectErrorBadges.java:172) at org.netbeans.modules.java.source.tasklist.IncorrectErrorBadges This can be caused by annotation processor, not enough memory to compile root. Was something of this the case? When you opened the file did it have an error badge?
I do not remember seeing an error badge on the file, but I am accustomed to there always being error badges somewhere in some of my source roots even when everything is in fact compilable. The IncorrectErrorBadges task sometimes runs but never really clears anything up, so the IDE is just scanning on and off all day for no reason. Deleting my cache folder and restarting does not help for long or at all. Frankly I do not care that much whether the index is 100% accurate, I just want the IDE to be quiet and stop draining my battery while I am trying to work. Is there no way to tell it to simply stop scanning unless and until I direct it to, and to use whatever cached index is available? The Scan on Demand module sounds like it would do just this, but it apparently does not.
The Scan on Demand module does not do this. It's pre background scan module which just don't do the up to date check and initial scan when the root was already scanned before. In pre NB 7.2 no features were available during the scan so it made sense. All other scans are done. For each source root there is a cache root having the "class" files for the sources. The javac sees both the cache and source root (not true during the initial scan when the javac in editor has empty source path until the cache is created). From that time the javac always sees both cache and sources. Disabling the scan will not only affect IDE features but will have impact on performance and memory usage as the javac will always complete the symbols missing in cache from sources (parsing -> ASTs, attributing the ASTs). After operation like VCS update you will likely end with OOM. There are 2 things which causing long scans and are mainly done just to update the error badges: 1) The IncorrectErrorBadges detector I will add at least the cmd line switch to disable it. If allowed I will also put it into options. 2) You can limit the scope of rescanned files after public API change in Tools/Options/Editor/Hints/Java/Dependency Scanning (by default it's all dependent roots).
There is already an cmd line option to disable the IncorrectErrotBadges -J-Dorg.netbeans.modules.java.source.tasklist.IncorrectErrorBadges.disable=true Jesse, can you look into cache_folder/errors/1/ there are err files like (./s1025/errors/1/org/netbeans/modules/java/api/common/project/BaseActionProvider.java.err) containing the reported errors. Are these errors which are not fixed by rescan related to processors? Thanks!
Created attachment 140948 [details] Thread dumps I have been running with IncorrectErrorBadges.disable, which seems to help. Still sometimes there are long, senseless rescans. http://statistics.netbeans.org/analytics/exception.do?id=695496 for example. Attaching a couple thread dumps after the IDE became mostly unresponsive despite having apparently plenty of free heap, and despite there no longer being any projects open.
I cannot say this will happen 100% of the time but it happens frequently on both mine and a colleagues computer (he stopped using nb over this). If you clone jruby git repository you can start netbeans and load jruby as a project. Then on command-line 'mvn clean; mvn'. Do this a few times and you should see scanning. We do have generated sources so perhaps it is rightfully rescanning a bit but this completely gets into an endless scanning state pretty easily. Another way I have seen this is to switch branches from the command-line: 'git co jruby-1_7', 'git co master'.
I don't understand how this issue is resolved. Of a typical 8 hour work day, I usually spend at least half an hour during the day just waiting for the Background scanning to finish (sometimes takes up to 10 minutes). During this time the IDE is completely unusable because it takes 10-20 seconds to respond to keypress and mouse clicks etc. It's hard to justify the use of Netbeans as my IDE under such conditions. Running Netbeans 8.0 under Linux, dependency scanning and error bagdes both disabled.
Continues to happen to me regularly unless I use IncorrectErrorBadges.disable, in which case I do not get rescanning but I still have #244383. All I really need is for the IDE to notice that there is an up-to-date *.class file on disk (from Maven compilation), acknowledge that its internal parser is hopelessly broken in this case, and use the externally produced classfile and make the badge go away.
Any chance we can re-open this issue? I wouldn't mind if you dedicated a version if only just to fix this slowness. It would be worth more than any new feature.