Community
Participate
Working Groups
Build ID: M20071023-1652 Steps To Reproduce: I am adding a new package and compilation unit programmatically like so: IPackageFragmentRoot root = getPackageFragmentRoot(project); IPackageFragment pack = root.createPackageFragment(PKG_NAME, false, monitor); try { pack.createCompilationUnit(FILE_NAME, templateName, false, monitor); } catch (JavaModelException e) {){ e.printStackTrace(); } I have run into what I think is a race condition where my code is causing my JavaProject to be added to the DeltaProcessor.projectCachesToReset HashSet *AFTER* DeltaProcessor#processResourceDelta clears out the projectCachesToReset HashSet. The result is that whenever I invoke JavaProject.findType(String), the lookup takes an exceedingly long time as the cache has to be rebuilt each time it is called. This is a highly intermittent problem, it only seems to happen the very first time that I launch Eclipse. (And I mean the *very* first time, i.e. after I unzip it). It seems like it should not be possible to have a JavaProject in this cache, as it is cleared out on any Workspace Modification. It seems like the creation of the package itself would eventually invoke DeltaProcessor#processResourceDelta and clear projectCachesToReset. This very well could be a problem in my code, but I wanted to inquiry as to the possibility of this scenario, and anything that you think could cause it? More information:
Looking at the code, I don't see how the projectCachesToReset could be left non-empty at the end of the operation. Do you have more details on how to reproduce this problem?
I don't have any other debugging information that would be helpful at this time. Please leave this bug open, if you can, I would like to revisit this at another time and try and produce a stand-alone example. It rarely happens in our product, but when it does, the performance takes a massive hit.
Dan, any news on this one?
Jerome, This bug has fallen off of my 'radar screen'. I do not believe my code is still using these APIs. So, it's not likely I will be digging any deeper into this problem. I am OK with closing if you feel it is not reproducible.
Thanks Dan. Closing then.
Verified for 3.5M2 using I20080914-2000.