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 28636 - Automounter task blocks FolderRecognizer
Summary: Automounter task blocks FolderRecognizer
Status: RESOLVED DUPLICATE of bug 29839
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: David Strupl
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2002-11-11 15:09 UTC by _ pkuzel
Modified: 2008-12-22 19:58 UTC (History)
1 user (show)

See Also:
Issue Type: TASK
Exception Reporter:

Attachments
Commented thread dump (7.86 KB, text/plain)
2002-11-11 15:13 UTC, _ pkuzel 		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 _ pkuzel 2002-11-11 15:09:11 UTC 
...
org.openide.loaders.DataFolder.getChildren(DataFolder.java:245)
org.netbeans.modules.editor.NbToolbarSupport.getToolbarObjects(NbToolbarSupport.java:820)
org.netbeans.modules.editor.NbToolbarSupport.addPresenters(NbToolbarSupport.java:726)
org.netbeans.modules.editor.NbToolbarSupport.refreshToolbarComponent(NbToolbarSupport.java:694)
org.netbeans.modules.editor.NbToolbarSupport.refreshToolbar(NbToolbarSupport.java:543)
org.netbeans.modules.editor.NbToolbarSupport.access$1200(NbToolbarSupport.java:94)
org.netbeans.modules.editor.NbToolbarSupport$7.propertyChange(NbToolbarSupport.java:289)
java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:252)
org.netbeans.core.windows.RegistryImpl.topComponentActivated(RegistryImpl.java:245)
...
Comment 1 _ pkuzel 2002-11-11 15:13:17 UTC 
Created attachment 7907 [details]
Commented thread dump
Comment 2 Petr Nejedly 2002-11-11 15:48:47 UTC 
Comments:
This is a bit overstated.
Painting is I/O as well and you can't get away without it.
Icon loading is I/O and you'll need to do it from there sometimes.
Bundle loading is I/O and is _usually_ done from AWT.
...

_Expensive_ I/O must not be done from AWT, that's it. The problem here
is that I/O was blocked by something else (a bug in automount) and
that caused the editor was caught in otherwise quite fast I/O,
by the way during opening of the editor, where there is pleny of other
I/O anyway.

Blame the automount (as I explained in the nbdev message), not editor
this time.
Comment 3 Jesse Glick 2002-11-11 16:03:05 UTC 
IMHO it is fine to access java.io.File (directly or indirectly) from
AWT, unless you have a specific reason to believe that the access will
be significantly slow. Most apps pause if you have a bad, slow network
disk. It is expected. Obviously making explicit network connections
(e.g. HTTP) should never be done from the AWT thread.
Comment 4 _ pkuzel 2002-11-11 16:19:38 UTC 
Generally agree, but in this case it proved to cause problem that can
be solved by asynchronous call followed by invokeLater.
Comment 5 _ pkuzel 2002-11-11 21:39:25 UTC 
Nenik was right, Automonter is the key.
Comment 6 David Strupl 2003-01-14 13:45:06 UTC 
Hehe, how can both of you can be sure that the problem in in
Automount? The problem is IMHO in FolderList. Moreover I think that
this is the same problem as 29839. Making this duplicate (although
this is a bit older but the other issue is a defect which more
correctly describes the situation).

*** This issue has been marked as a duplicate of 29839 ***