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.
Dual processor machine. Will attach stack trace - buffer wasn't big enough to catch all of it, but the important parts are there.
Created attachment 12794 [details] stack trace
Possibly let Jirka resolve the other weirdness with new service types first, but I think this is a seperate problem. Wanting to avoid the weirdness, I tried just copy-pasting ant execution (to create a custom executor to run the openide unit tests). I'm stunned by the number of layers here! Node -> Data Object -> FileObject -> Registry -> DOM Object -> ProxyLookup -> FolderLookup -> FolderInstance -> FileObject. (What exactly *do* the last five layers accomplish? No, I don't want to know). It's completely reproducable, so I'm attaching a better stack trace. BTW, I'm also curious why immediately after restarting there are 29 (!!) inactive request processor threads. I'll file that separately.
Created attachment 12795 [details] Stack trace from second run, no missing threads this time
As I haven't find the other issue, I'm commenting here. The inactive processors come from wrong usage of RP. Somebody is posting bulk of runnables into RP.getDefault() which is not designed for this usage. RP.getDefault() is multithreaded (artifical limit of 50 threads) so runs all the requests in parallel. I've added a bit of diagnostics to RP (the "Was:" part of the name) but it is still not enough (just shows that somebody abuses RP.getDefault(). In case of Was: VCS... it would be OK - there were more VCS commands running in paralel). I'll add more diagnostics there (class of the action) so we can nail down the culprit...
You haven't found the other issue because I wanted to diagnose who was doing it first, to file it correctly...and then my girlfriend stole the computer from me for the evening :-) Conceivably related: issue 38458 - possibly VCS trying (and failing) to refresh folders? At least it's something that could reasonably attempt 29 asynchronous operations after startup...
changing owner dkonecny -> pnejedly
The problem: dataObject.copy grabs the DataObjectPool "real atomicity support" and then performs the real operation (do copy), which fires events, and one of the listeners in effect waits for a FolderInstance. The FolderInstance is then processed in its own thread, but can't proceed with recognizing of files, while the DOP is "locked". Yarda, you've added the DataObjectPool guarding code. Shouldn't the final firing be performed out of the DOP guard?
That would be much better. The simplest fix is to first start runAtomicAction and then grab the DataObjectPool internal code. I can do it myself, if you want.
OK, yarda, it's yours.
Checking in loaders/src/org/openide/loaders/DataObjectPool.java; /cvs/openide/loaders/src/org/openide/loaders/DataObjectPool.java,v <-- DataObjectPool.java new revision: 1.19; previous revision: 1.18 done Processing log script arguments... More commits to come... RCS file: /cvs/openide/test/unit/src/org/openide/loaders/Deadlock38554Test.java,v done Checking in test/unit/src/org/openide/loaders/Deadlock38554Test.java; /cvs/openide/test/unit/src/org/openide/loaders/Deadlock38554Test.java,v <-- Deadlock38554Test.java initial revision: 1.1
Tim, please verify (just try it and if not happend mark VERIFIED), thanks in advance.
I can't reproduce it in [nb_36_rc1](200403141830)