I am seeing a pathological problem with the VCS module in Netbeans 4.1. It
happens when we use the "Project" file explorer for the Java 3D Netbeans
project, which I have configured for CVS access using the VCS versioning
manager. We are experiencing a hang of 30-40 seconds when first expanding the
list of files in the javax.media.j3d package. The CPU is pegged at 100% during
this time. It isn't exactly a deadlock, since it eventually comes back, but it
is some sort of pathological condition, probably due to thread/resource contention.

Our project has 386 *.java source files in the offending javax.media.j3d package
(which may be relevant, since we don't see this problem when exploring other
projects). I can reproduce this consistently in my environment, as can one of my
coworkers, but on some of our other machines, we don't see it.

Here are the instructions for reproducing it, assuming that you have the
java3d-1.4.0 project loaded (I can help you set that up, if it would help you
solve the problem).

1. Start Netbeans
2. In the "Projects" window, use the file explorer to:
   A. Open the "java3d-1.4.0" project
   B. Open the "src/classes/share" source directory
   C. Open the "javax.media.j3d" package

At this point it will hang for about 10-15 seconds before displaying the list of
file names, and for about another 20-25 seconds before you can open a file, or
do anything else. During the entire 30-40 seconds, the GUI is non-responsive: it
won't repaint damage cause by window exposure events nor will it respond to any
menu selections. At least two threads are pegged at 100% CPU usage during the
first 10-15 seconds and one thread is pegged at 100% CPU usage during the last
20-25 seconds (as observed with a performance meter).

I have attached two thread dumps, the first taken before the list of files in
the package was displayed (i.e., during the first 10-15 seconds), and the second
taken after the list of files was displayed, but before the GUI was responsive
(i.e., during the last 20-25 seconds). These are labeled threaddump1.txt and
threaddump2.txt, respectively.

NOTE: The problem does not happen if I first do a "CVS - Refresh Recursively" on
the "src/classes/share" source directory. In this case, the CVS refresh takes
about 5-7 seconds (as expected), during which time the GUI is responsive. The
CPU is not heavily used during that time. If I then expand the list of files in
the src package, it only takes about 1 or 2 seconds (during which time the GUI
is non-responsive, but it's so short a time one hardly notices).