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 29407 - ALL: Deleting VCS fileobject in Versioning explorer causes deadlock.
Summary: ALL: Deleting VCS fileobject in Versioning explorer causes deadlock.
Status: VERIFIED FIXED
Alias: None
Product: obsolete
Classification: Unclassified
Component: vcscore (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P2 blocker (vote)
Assignee: Martin Entlicher
URL:
Keywords: THREAD
Depends on:
Blocks:
 
Reported: 2002-12-09 14:49 UTC by Jiri Kovalsky
Modified: 2003-02-04 13:46 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Thread dump taken while IDE was deadlocked. (3.32 KB, text/plain)
2002-12-09 14:50 UTC, Jiri Kovalsky 		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 Jiri Kovalsky 2002-12-09 14:49:53 UTC 
Development build #200212090100 of NetBeans 4.0
Windows 2000 with FCS build #21 of JDK 1.4.1

Description:
============
Trying to delete VCS fileobject in Versioning
explorer always causes deadlock. This may lead to
data loss. Please fix this issue as soon as possible.

Description:
============
1. Mount CVS filesystem using Command-line Client.
2. Invoke "Versioning Explorer" on some
[Up-to-date] file.
3. Invoke "Delete" action on the fileobject.
4. IDE is freezed.
Comment 1 Jiri Kovalsky 2002-12-09 14:50:37 UTC 
Created attachment 8237 [details]
Thread dump taken while IDE was deadlocked.
Comment 2 Martin Entlicher 2002-12-09 19:41:59 UTC 
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...
Comment 3 Martin Entlicher 2002-12-09 19:56:46 UTC 
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.
Comment 4 rmatous 2003-01-21 14:29:50 UTC 
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).
Comment 5 Martin Entlicher 2003-01-21 14:38:40 UTC 
O.K., I'll try that...
Comment 6 Martin Entlicher 2003-01-21 17:39:38 UTC 
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...
Comment 7 Martin Entlicher 2003-01-22 10:18:15 UTC 
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.
Comment 8 Martin Entlicher 2003-01-22 12:27:00 UTC 
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
Comment 9 dmladek 2003-01-24 00:58:42 UTC 
OK, it's fixed:-)