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.
This issue was reported manually by sdedic. It already has 1 duplicates Build: NetBeans IDE 7.3 Beta 2 (Build 201211062253) VM: Java HotSpot(TM) 64-Bit Server VM, 23.5-b02, Java(TM) SE Runtime Environment, 1.7.0_09-b05 OS: Windows 7 User Comments: GUEST: copied SVN-versioned folder into another SVN-versioned folder (another project), then tried to cancel endless background scanning Stacktrace: java.lang.Exception: Scan canceled. at java.lang.Thread.getStackTrace(Thread.java:1567) at org.netbeans.modules.parsing.impl.indexing.LogContext.create(LogContext.java:115) at org.netbeans.modules.parsing.impl.indexing.LogContext.create(LogContext.java:108) at org.netbeans.modules.parsing.api.indexing.IndexingManager.refreshAll(IndexingManager.java:411) at org.netbeans.modules.parsing.api.indexing.IndexingManager.refreshAllIndices(IndexingManager.java:369) at org.netbeans.modules.versioning.indexingbridge.Bridge$1.call(Bridge.java:63)
Created attachment 129518 [details] stacktrace
Please see the exception report's message log. VCS events result in rapid re-scanning, results in a seemingly neverending background scan.
Found other reports for GIT -> changing component to general one
I can try and move copy/delete/move commands outside of the indexing bridge (run the commands without it). But is it the right way? I thought that was the goal of the indexing bridge - to run versioning commands manipulating with source files with bked indexing (inside the indexing bridge) and start the scanning only after the command finishes.
As the org.netbeans.modules.versioning.indexingbridge.Bridge is implemented, it really protects IndexingManager from interrupting of events during the single VCS operation. But the logs seem to record multiple calls to IndexingBridge itself, each of which schedules a refresh task (refreshAllIndices). Each of the refresh tasks ignores the fs events, but they are still executed one after each other, so even if they don't cancel each other, they still spend CPU on prolog/epilog/management of the change indexing. Isn't there a way how to batch them ?
fix: http://hg.netbeans.org/core-main/rev/e66b1f5f7f1f
Integrated into 'main-golden', will be available in build *201301030001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/e66b1f5f7f1f User: Ondrej Vrabec <ovrabec@netbeans.org> Log: #223997 - Rapid calls to IndexingManager.refreshAll from VCS Disconnecting the IndexingBridge in case of FS operations, they should already be invoked inside an AtomicAction which blocks the indexing anyway.