Created attachment 62985 [details]
thread-dump

To properly answer the collocation query the clearcase module has to execute the 'cleartool' process. So the solution to
this is to avoid calling collocation query in awt. Reassigning for evaluation.

Milosi, please take a look at it. Thanks.

Introduced by shared libraries.
SharableLibrariesWizard and SharableLibrariesPanel should call call CQ outside awt.
Shouldn't the clearcase provide the resut of CQ from cache?
 

Re. "Shouldn't the clearcase provide the resut of CQ from cache?" - I think so. The CQ implementation should be as quick
as possible as Query is or can be used in AWT thread throughout the IDE. We could fix this instance
(MakeSharableVisualPanel) but I'm sure there will be others. This code has been there since 6.1 and there were no
problems with other VCS systems.

Passing back to clearcase for evaluation of caching options. Does running cleartool gives you list of checkout roots? If
so perhaps you could call it in background after IDE startup and cache the result? Just brainstorming.

Re. "Shouldn't the clearcase provide the resut of CQ from cache?" - I think so.
Yes, we could cache CQ results or similar data ... the first query would still be slow though.

The CQ implementation should be as quick as possible as Query is or can be used in AWT thread throughout the IDE.
You are calling some unknown code, why are you making assumptions it is so fast it can be safely run in AWT? Take the
infamous SharabilityQuery as an example. Not only is it slow but it is generally unsafe to call it from any callback
thread, not speaking about EDT.

We could fix this instance (MakeSharableVisualPanel) but I'm sure there will be others. This code has been there since
6.1 and there were no problems with other VCS systems.
Other system just browse disk structures which is faster than talking over the network, which is the case of clearcase.

Does running cleartool gives you list of checkout roots?
It unfortunately does not. We will think about caching something so subsequent CQs run faster.

However, I still think that the primary cause of this issue is calling the query in EDT. You can you the
AsynchronousValidatingPanel to validate the input outside EDT.

> Shouldn't the clearcase provide the resut of CQ from cache?
There always will be situations when nothing isn't cached yet...

> Does running cleartool gives you list of checkout roots?
> It unfortunately does not. We will think about caching something so subsequent CQs run faster.
the thing is we have to do it the hard way - run a set o commands to find out what is the root from a cc view and as far
i know we already cache other results from previous getTopmostManagedParent calls. However, i will peek into the code if
there is a chance to improve something...

> The CQ implementation should be as quick as possible as Query is or can be used in AWT thread throughout the IDE.
agree with maros at this point - you never know how long it will take vcs to retrieve the needed data

I doubt it is practical for every caller of CQ to do so asynchronously. Much better if the clearcase module can keep a
cache that makes the call fast in most cases, and user will just have to deal with a short freeze for other cases.

> much better if the clearcase module can keep a cache that makes the call fast in most cases, 
we already do that
> and user will just have to deal with a short freeze for other cases.
just for the record - cleartool contacts the server (if we like it or not), there is no guarantee it always will be a short one...

After a bit of struggle we found out why this happens. First of all, ClearcaseVCS.areCollocated() should NOT be called
by the CollocationQuery. The problem is that CollocationQuery queries ClearcaseVCS in spite of the fact that it is NOT
registered in META-INF/services as a CollocationQueryImplementation. It IS in fact registered but only as a
VersioningSystem and just happens to implement the CollocationQueryImplementation. Yarda told us that this is an
unfortunate misfeature of the Lookup implementation and nothing can be done about it. So we will think about a way to
work around this on our side.

BTW, while debugging the code we saw that the wizard is calling CQ with nonexistent, bogus folders which also slows
things down. CQ.isCollocated("Y:\lib", "Y:\vob1\lib") where "Y:\lib" does not exist and the wizard was given
"Y:\vob1\lib" as the library folder. I'd recommend you check your code or file a bug.

Regarding Lookup: I guess you mean that if you have

---%<--- META-INF/services/A
C
---%<---
public class C implements A, B {}
---%<---

then Lookup.getDefault().lookup(B.class) will normally return null, but will return C in case someone has previously
called Lookup.getDefault().lookup(A.class)? If so, ugly indeed - a byproduct of the fact that Lookup was designed to
mirror the Java type hierarchy even though this has little or no benefit for its users and does not work well with
META-INF/services.


"the wizard is calling CQ with nonexistent, bogus folders" - please file a separate bug for this so it does not get
forgotten. If you ran across this in the debugger, you will be the best person to file it.

jglick: yes, this is what's happening

Re. "CQ with nonexistent, bogus folders" - MakeSharableVisualPanel1 calls CQ on Libraries Folder location specified by
user which very likely does not exist. The purpose is to warn user if location is not collocated with the project.
That's something for Milos to fix. Though I would thought it is OK to call CQ with non-existing folder. 

Versioning systems no longer implement CQI.
bff70e9c7b9a

Integrated into 'main-golden', available in NB_Trunk_Production #285 build
Changeset: http://hg.netbeans.org/main/rev/bff70e9c7b9a
User: Maros Sandor <msandor@netbeans.org>
Log: #137554: Versioning systems no longer implement CQ

verified in NB Dev (20080724)