Created attachment 93008 [details]
thread dump

thread dump during frozen IDE 
Product Version: NetBeans IDE Dev (Build 091230-b1ad2996ff17)
Java: 1.6.0_14; Java HotSpot(TM) Client VM 14.0-b16
System: SunOS version 5.10 running on x86; UTF-8; en_US (nb)

It seems to be duplicate of 110904. I wasn't able to reproduce on my Ubuntu Linux. Are there any special steps or maybe Solaris specific?

It may be NFS-based filesystems specific. Home is on NFS folder and home is the default start folder?

Yes NFS could be the reason - Vladimir could you check if the problem applies to local FS as well? I think just opening something from local FS and invoking Open project again will show it, as dialog remembers last location. Thank you.

Or maybe please give me instructions (offline) how to mount NFS where you are experiencing problems. I tried to find some sample public NFS server on inet, but failed, probably because of security issues.

Hi David,
I do not have such issue now, but you can easily emulate it.
Just put on line 1115 of file DirectoryChooserUI.java
                    try {
                        Thread.sleep(10000);
                    } catch (InterruptedException ex) {
                        Exceptions.printStackTrace(ex);
                    }
that can help you to simulate long NFS for
                    node = new DirectoryNode(file);
                    node.loadChildren(fileChooser, true);
and you will see frozen UI
I've tried and it is 100% reproducible :-)

Yep, thanks for the hint, I thought about it too but was too lazy :-)

> I do not have such issue now, but you can easily emulate it.

Is this a real issue then?

(In reply to comment #8)
> > I do not have such issue now, but you can easily emulate it.
> 
> Is this a real issue then?

as soon as file system has *any* slowness (i.e. NFS is slow) => yes.
Btw, from implementation point of view DirectoryChooserUI.java has an error.
There is no reason to do in EDT the following:
 methodCalledFromEDT() {
  task = RP.post(Runnable {
            long operation here...
         });
  task.wait();
 }
because from  it's the same as 
 methodCalledFromEDT() {

sorry, interrupted :-)
impl is incorrect, because long operation still locks EDT

Yes, agreed with Vladimir. We had various reports of slowness in the past, probably coming from slower FS.

fixed, updateTree calls optimized and queue for handling update requests introduced:
4515790622ab

Integrated into 'main-golden', will be available in build *201003230200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/4515790622ab
User: Dafe Simonek <dsimonek@netbeans.org>
Log: #179124: updateTree call frequency lowered, introduced blocking queue run in RequestProcessor to be able to handle multiple update requests outside of event dispatch thread

*** Bug 110904 has been marked as a duplicate of this bug. ***