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.
Attached is thread dump of the lock during the core-unit test run on Windows 2000.
Created attachment 26820 [details] Thread-dump
Imho org.openide.filesystems.FileObject.toString(FileObject.java:136) is too expensive and is responsible for the deadlock.
/cvs/openide/fs/src/org/openide/filesystems/FileObject.java,v <-- FileObject.java new revision: 1.4; previous revision: 1.3
Another interpretation is that the "Refresh Loader Pool" thread is at fault for locking the DataObjectPool. If all the refreshing were to run in the same thread as "Folder recognizer" there would be no problem (I think). The patch may solve this particular deadlock but it's far from clear to me that it would solve other similar problems. If possible, I would recommend instead fixing DataObjectPool.stateChanged to do its work in the folder recognizer thread. IIRC the idea of the folder recognizer thread is that all major DS work should happen there so that DS and Lookup do not deadlock one another (as is happening here).
For a while I thought Jesse is right. But I guess he is not. It is true that FolderList.changedDataSystem is called under a (package) private lock, but no foreign code is executed there: FolderList list = find (folder, false); if (err.isLoggable(err.INFORMATIONAL)) { err.log ("changedDataSystem: " + folder); // NOI18N } if (list != null) { list.refresh (); } The only foreign code was the FileObject.toString() (and only due to logging) which Radek fixed. So I am affraid there is not much else that shall be fixed. Of course anyone is welcomed to write a test that will prove there is a deadlock...