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.
Summary: | IDE is frozen and not redrawn when for "Open Project..." | ||
---|---|---|---|
Product: | platform | Reporter: | Vladimir Voskresensky <vv159170> |
Component: | Directory Chooser | Assignee: | David Simonek <dsimonek> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | anebuzelsky, pnejedly, vkvashin |
Priority: | P2 | ||
Version: | 6.x | ||
Hardware: | PC | ||
OS: | Solaris | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 182605 | ||
Bug Blocks: | |||
Attachments: | thread dump |
Description
Vladimir Voskresensky
2009-12-30 05:46:40 UTC
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. *** |