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.
Looks like the VcsGroupChildren does too much work when somebody is trying to destroy the data object (setValid (false)).
Created attachment 3637 [details] Thread dump
The refreshAll() method should probably do the work lazily. What do you think Milos?
first: Does this happen *everytime*? Second: why is it P1? third: what about mentioning the build etc. To Martin: I'm not sure. What do you mean by lazily? Schedule the stuff in the request processor will just delay the whole thing and not guearantee that it will be ok. I noticed 3 threads doing dataObject.setValid() at the same time. Automount, FolderRecognizer and Openide.. <rant> THis is getting quite frustrating. The threading in openide changes constantly, so do the inner workings of filesystem/datasystems. it's not only thins case, it happened to us many times lately. And noones tells what to avoid it or what to write code so that one doesn't get into such troubles. (Not even mentioning any guarantees). The number of threads is raising constantly. this can't go on endlessly this way. :( </rant>
It seems to me, that the Openide Request Processor is deadlocked with FolderRecognizer. The problem is, that we run org.netbeans.modules.vcscore.grouping.VcsGroupChildren.getFilesInGroup in Request Processor, which later calls FolderList.getChildrenList(), which waits for FolderRecognizer. But FolderRecognizer is invalidating another DataObject, which close the circle. If we spawn a task in RequestProcessor for setKeys(getGroups()); in refreshAll() that should fix the problem (at least I hope so).
*nods* probably yes, I got another mostly performance improvement. The Task that runs the refreshAll() should be checked if in the queue and if so not run again. (so that it's not run 20 times for 20 invalidated dataobjects (which happens prolly when switching the projects..)
Doing the refresh with a small delay is good solution. Anyway I am CCing Petr to check whether the brokendatashadows test should not be also done with a delay, as is shown in the stacktrace it is run in really dangerous places...
Ok, I'll fix it over the weekend or on Monday.
fixed in main trunk and release33 branch. The fix is quite safe and straightforward. However I'm not sure if it's worth making it a 330_CANDIDATE. Yarda, how ofter was this deadlock? If that was a common case, I suggest we put it in the 330 branch as well, otherwise I think it can wait till 3.3.1 http://vcscore.netbeans.org/source/browse/vcscore/src/org/netbeans/modules/vcscore/grouping/VcsGroupChildren.java.diff?r1=text&tr1=1.5&r2=text&tr2=1.6&f=h
changing to waiver.
I haven't seen this kind of dead lock so far. Verified in development build #200112070331 of NetBeans 3.3.1.
Resolved for 3.4.x or earlier, no new info since then -> closing.