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: | ALL: Deleting VCS fileobject in Versioning explorer causes deadlock. | ||
---|---|---|---|
Product: | obsolete | Reporter: | Jiri Kovalsky <jkovalsky> |
Component: | vcscore | Assignee: | Martin Entlicher <mentlicher> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | mentlicher |
Priority: | P2 | Keywords: | THREAD |
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Windows ME/2000 | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | Thread dump taken while IDE was deadlocked. |
Description
Jiri Kovalsky
2002-12-09 14:49:53 UTC
Created attachment 8237 [details]
Thread dump taken while IDE was deadlocked.
So we must perform datasystem operation (DataLoaderPool.setPreferredLoader()) in a thread, that does not have any locks from filesystems. I'll do it lazily an a new thread... Well, calling DataLoaderPool.setPreferredLoader() always in a separate thread might have a bad impact on performance. Can this be solved in filesystems? How can I know what can I call in createReference() and what not? I need to assign the loader as soon as possible so that a "default" dataobject is not created and later thrown away. Is there a better approach to achieve that? Thanks. I think, that this problem must be solved in VcsVersioningSystem.createReference. This piece of code is definitely responsible for deadlock. What can be called in createReference ? This is general problem that must be solved if you in subclass overwrite arbitrary method. Here according to javadoc you get FileObject and should return Reference. As far as I undrestand, you need to react to fact that FileObject was created. You choose createReference as a convenient entry point. Instead of createReference you could try to listen on FileSystem (FileChangeListener). O.K., I'll try that... I guess this deadlock is not repoducible :-( At least I was not able to reproduce it on WinNT. However I'll try to implement the workaround... I can not use FileChangeListener for that purpose, but I'll use a different hack. I'll set the desired data loader directly in file attributes. Fixed in the main trunk. The versioning loaders are set directly in file attributes. /cvs/vcscore/src/org/netbeans/modules/vcscore/VcsVersioningSystem.java,v <-- VcsVersioningSystem.java new revision: 1.34; previous revision: 1.33 /cvs/vcscore/src/org/netbeans/modules/vcscore/versioning/VersioningFileSystem.java,v <-- VersioningFileSystem.java new revision: 1.20; previous revision: 1.19 /cvs/javacvs/src/org/netbeans/modules/cvsclient/versioning/JavaCvsVersioningSystem.java,v <-- JavaCvsVersioningSystem.java new revision: 1.25; previous revision: 1.24 OK, it's fixed:-) |