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 36402

Summary: MetaInfServicesLookup sometimes failing to return results
Product: platform Reporter: Jesse Glick <jglick>
Component: LookupAssignee: Jaroslav Tulach <jtulach>
Status: VERIFIED FIXED    
Severity: blocker Keywords: RANDOM, THREAD
Priority: P2    
Version: 3.x   
Hardware: PC   
OS: Linux   
Issue Type: DEFECT Exception Reporter:

Description Jesse Glick 2003-10-02 20:57:09 UTC 
Not sure exactly what to point to, because the
problem does not seem reproducible. But very
frequently over the past couple of weeks,
Lookup.default has failed to return a result for
basic queries which should be in MISL - and
printing L.d shows that it does contain a MISL
which should have the proper modules. The only
significant changes I know of were by you, re.
AbstractLookup.Pair.

Here is an example:

java.lang.NullPointerException
	at
org.netbeans.core.windows.RegistryImpl.<init>(RegistryImpl.java:64)

L.d.l(WindowManager.class) returns null.

Same has happened recently for DataLoaderPool,
InstalledFileLocator, perhaps other classes. Quite
unreproducibly - I have had it happen with IFL in
a fresh user dir, then I instrumented the class
making the query and ran again with a fresh user
dir and it did not happen again - so seems to be a
race condition.

Of course, could also be a problem in ProxyLookup
(i.e. NbTM.Lkp).
Comment 1 Jaroslav Tulach 2003-10-03 20:53:48 UTC 
There is probably a hole in MetaInf that could in case of two threads
accessing it return null for the later thread. I can get rid of this
and see if that helps.
Comment 2 Jaroslav Tulach 2003-10-03 21:01:21 UTC 
*** Issue 36228 has been marked as a duplicate of this issue. ***
Comment 3 _ tboudreau 2003-10-03 21:25:44 UTC 
In a build today, several times the contents of the execution,
compiler and debugger property editors suddenly became empty (after
having worked earlier).  Related?
Comment 4 Jesse Glick 2003-10-04 00:03:53 UTC 
Provisionally marking as a race condition.
Comment 5 Jaroslav Tulach 2003-10-05 12:26:10 UTC 
I guess this is caused by the fix of issue 36035, a deadlock due to
strong locking in lookup, I can try to tight it up a bit again,
meanwhile you can try against version 1.3 of MetaInfLookup.
Comment 6 Jaroslav Tulach 2003-10-05 14:20:08 UTC 
I have fixed one problem. Maybe that was the one of this issue.

AbstractLookup.java
new revision: 1.41; previous revision: 1.40

MetaInfServicesLookup.java
new revision: 1.6; previous revision: 1.5
Comment 7 Jesse Glick 2003-10-07 17:56:45 UTC 
*** Issue 36458 has been marked as a duplicate of this issue. ***
Comment 8 Jaroslav Tulach 2004-01-15 09:51:21 UTC 
*** Issue 36161 has been marked as a duplicate of this issue. ***
Comment 9 Lukas Hasik 2004-02-25 18:39:18 UTC 
x