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.
Deadlock occured when trying to delete large folder. See attached FTD.
Created attachment 3540 [details] FTD
I think that this thread is guilty: at org.netbeans.modules.vcscore.util.virtuals.VcsRefreshRequest.run (VcsRefreshRequest.java:172) Reassigned to mkleint@netbeans.org
it's an javacvs/vcscore issue. I'll try to fix it..
More info: deleted folder was under javacvs ;-)
who would have guessed that.. ;) BTW: can you 100% reproduce it each time? or was it a one shot deadlock?
I am afraid that it was only 'one shot' deadlock. I didn't see it anymore.
hmm I thought so.. here's my interpretaion of the deadlock so far: You were deleting a big scale delete. accidentaly at the same time a background refresh was happening that sadly interfered with the deleting stuff and caused the deadlock. Proposed solution: I'll check during the periodic refresh for any upcoming deleted files and such an action occurs the refresh will be postponed. Additional measure: The actual point of deadlock was that a file was being removed and at the same time an attribute was written to the .nbattrs file that the delete wanted to access as well (by the refresh). I guess the Preffered Virtual loader doesn't have to be written to .nbattrs file and can be handled dynamically from the filesystem's attribute handling. the DataLoaderPool.setprefferedloader() method won't actually write the attribute down, but rather just fire the prop. change and notify everyone the loader has changed. I guess when the attribute is reset, we need to access the .nbattrs file to check if there was no other prefferd loader.
I have a solution ready, just testing it some more. Solution: 1. Interrupt the running VcsRefresher if any request for preffered refresh comes in. This will cause the scheduling of the refresh and prevents the thread from interrupting the operations in other threads. This is a good risk-reducing measure, will not fix the actual problem IMHO. 2.Avoid writing the VirtualDataLoader as preffered loader to the nbattrs file. during the delete of files the ide attempts to delete the attributes of the file in the .nbattrs file. We should not write the virtualdataloader, but rather store it in the fileobject's reference. This way we'll have the info dynamic and won't need to write to the disk file. It both prevents the deadlock in the stacktrace but also has performance implications.
fixed in main trunk. (25/Nov/2001) As previously described. Also removed FileObject.findResource() and FileObject.refresh calls from the AbstractFileSystem.Info.outputStream() method implementation..
merged into the release33 branch. 3.3.0_CANDIDATE, however the keyword is not available yet :)
I have tried similar stuff (refreshing during deleting) but no dead- lock appeared. Unreproducable things are very hard to reproduce :-) and therefore I assume it was fixed. Verified in development build of NetBeans 3.3 #200111260100.
added the candidate keyword
Created attachment 3598 [details] fix changes.
won't be integrated to 330.
Resolved for 3.4.x or earlier, no new info since then -> closing.