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 Dev (Build 201204040400) VM: Java HotSpot(TM) Client VM, 20.0-b11, Java(TM) SE Runtime Environment, 1.6.0_25-b06 OS: Windows 7 User Comments: GUEST: scanning projects hanging Stacktrace: java.lang.Exception: Scan canceled. at java.lang.Thread.getStackTrace(Thread.java:0) at org.netbeans.modules.parsing.impl.indexing.LogContext.create(LogContext.java:109) at org.netbeans.modules.parsing.impl.indexing.LogContext.create(LogContext.java:102) at org.netbeans.modules.parsing.impl.indexing.PathRegistry.scheduleFirer(PathRegistry.java:820) at org.netbeans.modules.parsing.impl.indexing.PathRegistry.resetCacheAndFire(PathRegistry.java:814) at org.netbeans.modules.parsing.impl.indexing.PathRegistry.access$500(PathRegistry.java:85)
Created attachment 118683 [details] stacktrace
Two reports: The second (http://statistics.netbeans.org/exceptions/exception.do?id=564018), the time is spent in native call java.io.WinNTFileSystem.getLastModifiedTime(Native Method). No IO contention from the IDE. Either other application does intensive IO or slow FS. The IDE needs to detect changed file after start, so it needs to get the lastModifiedTime. The first report (http://statistics.netbeans.org/exceptions/exception.do?id=571242) seems to be more interesting. There seems to be IO contention among the scan and git: "GitRefresh" (RUNNABLE): java.io.WinNTFileSystem.getLastModifiedTime(Native Method) java.io.File.lastModified(Unknown Source) org.eclipse.jgit.treewalk.FileTreeIterator$FileEntry.getLastModified(FileTreeIterator.java:192) org.eclipse.jgit.treewalk.WorkingTreeIterator.getEntryLastModified(WorkingTreeIterator.java:480) org.eclipse.jgit.treewalk.WorkingTreeIterator.compareMetadata(WorkingTreeIterator.java:705) org.eclipse.jgit.treewalk.WorkingTreeIterator.isModified(WorkingTreeIterator.java:734) org.netbeans.libs.git.jgit.commands.StatusCommand.run(StatusCommand.java:224) org.netbeans.libs.git.jgit.commands.GitCommand.execute(GitCommand.java:72) The git slows down the crawler. The git operation is not wrapped by vcsindexing bridge. Reassigning to VCS for evaluation.
> The git slows down the crawler. True, but once inside a git command we cannot pause and let indexing finish first. We check if indexing is running before the refresh command is started - or at least that's what we do after restart and projects opening. But i think it's checked only right after project opening and not every time. We could extend that to situations when scanning's running after a refactoring etc. > The git operation is not wrapped by vcsindexing bridge. Right and should not be, the command is a status command (read only command) that does not modify files. The original intention for vcsindexingbridge was to block parsing/indexing for the time any *modifying* command's running. I could wrap all commands in indexingbridge call but that would block parsing API too often. Or you could add a method to the API for also read-only commands and handle the situation differently?
>True, but once inside a git command we cannot pause and let indexing finish >first. Yes. In this case nothing can be done. >We could extend that to situations when scanning's running after a refactoring etc. If it's possible it would make situation better. >status command (read only command) that does not modify files. In this case no vcsindexing bridge is not needed.
>>We could extend that to situations when scanning's running after a refactoring etc. >If it's possible it would make situation better. I'll change it for 7.3. Will also work as the fix for bug #208185
fix: http://hg.netbeans.org/core-main/rev/fc1e8d83a60b
Integrated into 'main-golden', will be available in build *201207241500* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/fc1e8d83a60b User: Ondrej Vrabec <ovrabec@netbeans.org> Log: #211634 - Scanning time spent in crawler