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 169815 - Module system events delivered sooner than initialization is finished
Summary: Module system events delivered sooner than initialization is finished
Status: RESOLVED WONTFIX
Alias: None
Product: platform
Classification: Unclassified
Component: Module System (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Jesse Glick
URL:
Keywords: THREAD
Depends on:
Blocks:
 
Reported: 2009-08-04 12:41 UTC by Jaroslav Tulach
Modified: 2009-08-04 23:42 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
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 Jaroslav Tulach 2009-08-04 12:41:29 UTC 
Once Jesse expressed a worry that some pieces of module code can be triggered sooner than the module initialization is 
over. The original suspect was Module.firePropertyChange, however there is another possible problem. As issue 159714 
shows, module system can deliver lookup notifications while holding the ModuleManager lock. See
http://www.netbeans.org/nonav/issues/showattachment.cgi/77779/deadlock.txt
and especially:
	at org.netbeans.modules.editor.settings.storage.StorageImpl$Filters$1.resultChanged(StorageImpl.java:491)
	- locked <0x00007f18a4e04b28> (a java.util.HashMap)
	at sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.openide.util.WeakListenerImpl$ProxyListener.invoke(WeakListenerImpl.java:450)
	at $Proxy2.resultChanged(Unknown Source)
	at org.openide.util.lookup.ProxyLookup$1Notify.run(ProxyLookup.java:173)
	at org.openide.util.lookup.ProxyLookup.setLookups(ProxyLookup.java:179)
	at org.openide.util.lookup.ProxyLookup.setLookups(ProxyLookup.java:119)
	at org.netbeans.core.startup.MainLookup.moduleClassLoadersUp(MainLookup.java:118)
	at org.netbeans.core.startup.MainLookup.systemClassLoaderChanged(MainLookup.java:106)
	at org.netbeans.core.startup.NbInstaller.load(NbInstaller.java:301)
	at org.netbeans.ModuleManager.enable(ModuleManager.java:906)
I am not sure how big problem this is, but if it is possible source of bugs, then the lookup can be instructed to 
delay the delivery of events until ModuleManager leaves its lock via ProxyLookup.setLookup(deliveryExecutor, arr).
Comment 1 Jesse Glick 2009-08-04 23:42:27 UTC 
The MM lock is acquired in this case by autoupdate.services.OperationSupportImpl. From the module system there is no
telling when it would be released, so deferring notification until the lock is released is not going to work
(synchronous observers would see the new contents of lookup before the event); and delivering notifications
asynchronously would be incompatible and possibly lead to race conditions and randomly failing tests.

Anyway the module system's lock does not seem to have been involved in the deadlock mentioned.