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.
Cleartool is not available, IDE won't start. WARNING [org.netbeans.modules.clearcase]: java.io.IOException: Invalid cleartool output: cleartool: Error: Unable to contact albd_server on host 'x.x.x.x' FINEST [org.netbeans.modules.clearcase]: getTopmostManagedParent no root for D:\SunWork\test\JavaApplication10 FINER [org.netbeans.modules.clearcase]: getTopmostManagedParent D:\SunWork\test\localhistory FINEST [org.netbeans.modules.clearcase]: getTopmostManagedParent no cached root for D:\SunWork\test\localhistory FINE [org.netbeans.modules.clearcase.client.Cleartool]: Cleartool: Creating cleartool process...
IDE starts, its just that it takes a couple of years...
Created attachment 57055 [details] Thread dump
I have tested it and startup is really slow. However clearcase module is not to blame, the clearcase filesystem driver hangs and timeouts after a long time. See attached thread dump where you can see that AWT is blocked by project system. I will reassign to projects for evaluation of moving filesystem operations out of AWT.
msandor: "However clearcase module is not to blame, the clearcase filesystem driver hangs and timeouts after a long time." The project system part is a fairly simple getProjectDirectory() call, which returns instantly on sane filesystems and which cannot be "optimized" in any possible way I can think of. -> so it's clearly clearcase fault, not project system.
Closing then.
It's really annoying whenever it happens. Can't it be really resolved somehow?
IMO any code that accesses file system from AWT can run into this so I suggest we either: 1) won't fix it 2) check the whole IDE codebase for such code and fix it
changing all code that accesses the filesystem from awt is a task of epic proportions with unclear results anyway.. can the clearcase support somehow detect this state without actually hanging?
As I wrote before, IDE CC support is NOT guilty. It is the CC OS file system driver that hangs the machine.
As mkleint says, fixing it on our side is practically impossible. It is up to CC admins to setup more reasonable CC behavior.
Closing.