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.

Bug 104000 - apisupport's SourceForBinaryQueryImplementation randomly fails
Summary: apisupport's SourceForBinaryQueryImplementation randomly fails
Status: RESOLVED FIXED
Alias: None
Product: apisupport
Classification: Unclassified
Component: Project (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Jesse Glick
URL:
Keywords: RANDOM, THREAD
Depends on: 107569
Blocks:
  Show dependency tree
 
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
Exception Reporter:

Attachments
Patch to the SFBI. (1.69 KB, text/plain)
2007-05-15 17:27 UTC, Jan Lahoda 		Details
Add an attachment (proposed patch, testcase, etc.)

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