Bug 104000 - apisupport's SourceForBinaryQueryImplementation randomly fails
apisupport's SourceForBinaryQueryImplementation randomly fails
Status: RESOLVED FIXED
Product: apisupport
Classification: Unclassified
Component: Project
6.x
All All
: P2 (vote)
: 6.x
Assigned To: Jesse Glick
issues@apisupport
: RANDOM, THREAD
Depends on: 107569
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-15 17:25 UTC by Jan Lahoda
Modified: 2007-06-21 18:53 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
:


Attachments
Patch to the SFBI. (1.69 KB, text/plain)
2007-05-15 17:27 UTC, Jan Lahoda
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Lahoda 2007-05-15 17:25:54 UTC
[recent sources]

It seems that the apisupport's SourceForBinaryQueryImplementation
(org.netbeans.modules.apisupport.project.queries.SourceForBinaryImpl) randomly
fails to resolve the project's jar to sources. It seems to be caused by
inability to resolve the cluster in
org.netbeans.modules.apisupport.project.queries.SourceForBinaryImpl.getModuleJarClusterPath

To reproduce, apply the attached patch to apisupport/project (should log a
message each time ${cluster} cannot be resolved for a module), open a lot of
NetBeans projects (from the NB standard distribution), wait for the reparse to
finish and restart the IDE. You should see log message(s) complaining that the
cluster(s) for module(s) cannot be resolved. (It may be necessary to restart the
IDE more than once to reproduce, the problem seems to be quite random.)

This causes a lot of headaches to Java infrastructure, especially tasklist is
forced to reparse a lot of files on startup, as their classpath changed (the
classpath stored in the caches is after applying SFBQ).
Comment 1 Jan Lahoda 2007-05-15 17:27:25 UTC
Created attachment 42421 [details]
Patch to the SFBI.
Comment 2 Jan Lahoda 2007-06-11 17:53:32 UTC
I think I found the problem: the SourceForBinaryQuery is called from more than
one thread, calls in turn the org.netbeans.modules.apisupport.project.Evaluator
and it does not handle access from multiple threads correctly. Consider calling
Evaluator.delegatingEvaluator(true) from two threads:
0. "thread 1" calls Evaluator.delegatingEvaluator(true)
1. "thread 1" reset == true, loadedModuleList == false => calls reset method
2. "thread 1" set loadedModuleList to true (in "reset" method)
3. "thread 1" sleeps
3. "thread 2" calls Evaluator.delegatingEvaluator(true)
4. "thread 2" reset == true, loadedModuleList == true => do not call reset
method, return cached delegate (which does not know about "cluster" property).
Comment 3 Jesse Glick 2007-06-11 18:00:37 UTC
So a simple race condition, then.
Comment 4 Antonin Nebuzelsky 2007-06-20 12:56:03 UTC
Jesse, any chance to have this fixed for M10?
Comment 5 Jesse Glick 2007-06-20 22:37:13 UTC
Can you verify?

Checking in Evaluator.java;
/shared/data/ccvs/repository/apisupport/project/src/org/netbeans/modules/apisupport/project/Evaluator.java,v  <-- 
Evaluator.java
new revision: 1.23; previous revision: 1.22
done


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo