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.

Bug 196140 - Switching project groups very often hangs on 70%
Summary: Switching project groups very often hangs on 70%
Status: RESOLVED DUPLICATE of bug 182830
Alias: None
Product: java
Classification: Unclassified
Component: Source (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P3 normal (vote)
Assignee: Jan Lahoda
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2011-03-01 07:46 UTC by lubos
Modified: 2011-03-07 07:47 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
thread dump (19.27 KB, text/plain)
2011-03-04 12:49 UTC, lubos 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description lubos 2011-03-01 07:46:53 UTC 
Product Version = NetBeans IDE 6.9.1 (Build 201011082200)
Operating System = Windows XP version 5.1 running on x86
Java; VM; Vendor = 1.6.0_22
Runtime = Java HotSpot(TM) Client VM 17.1-b03
Comment 1 lubos 2011-03-01 07:49:20 UTC 
It happens to all my collegues.
We have about 20 maven projects in each group.
Once it gets stuck on 70% it NEVER recovers (tried to wait all night)
Comment 2 Marian Mirilovic 2011-03-02 06:37:28 UTC 
Could you please generate thread-dump at the time of hang and attach it here and reopen? Thanks in advance.
http://wiki.netbeans.org/GenerateThreadDump
Comment 3 lubos 2011-03-04 12:49:47 UTC 
Created attachment 106707 [details]
thread dump
Comment 4 Jesse Glick 2011-03-04 14:30:23 UTC 
java.source.classpath.CacheClassPath.getResources is doing work synchronously in the project open hook, which I have never understood - can't it mark the Java index as dirty but return quickly?

Anyway the real performance problem is hard to pinpoint here. Opening the Java index is pathologically slow, and the time is being spent in Windows filesystem calls. From a single thread dump it is impossible to know whether a single I/O call is simply hung, or whether some bug in the index loading code is causing it to go into some endless loop repeatedly opening the same or different directories. Maybe still INCOMPLETE.

(Why is the Filesystems API involved here? I was under the impression the indexer worked at the java.io.File level whenever possible.)
Comment 5 Jan Lahoda 2011-03-07 07:47:23 UTC 

*** This bug has been marked as a duplicate of bug 182830 ***