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 35793 - org.netbeans.api.registry.Context.putObject() cause deadlock
Summary: org.netbeans.api.registry.Context.putObject() cause deadlock
Status: CLOSED WONTFIX
Alias: None
Product: projects
Classification: Unclassified
Component: Generic Infrastructure (show other bugs)
Version: 3.x
Hardware: PC All
: P1 blocker (vote)
Assignee: Vitezslav Stejskal
URL:
Keywords: THREAD
Depends on:
Blocks:
 
Reported: 2003-08-26 17:05 UTC by Adam Sotona
Modified: 2004-04-19 16:39 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Thread Dump (11.12 KB, text/plain)
2003-08-26 17:06 UTC, Adam Sotona
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Sotona 2003-08-26 17:05:35 UTC
org.netbeans.api.registry.Context.putObject()
called during process of instantiation from
template (from different thread) cause deadlock.
It can occure even in other situations but this
case is 100% reproducible.
Comment 1 Adam Sotona 2003-08-26 17:06:13 UTC
Created attachment 11446 [details]
Thread Dump
Comment 2 pzajac 2003-08-27 09:24:05 UTC
David, can you look to the deadlock?
Comment 3 David Konecny 2003-09-01 22:15:16 UTC
Please attach the whole thread dump. It seems to me that something is
missing.

From the attached stack trace it looks to me that problem is:
project's NewFileAction instantiates template in "Module-Actions"
thread and waits for ConfigurationManager.MUTEX.enterReadAccess(). Who
holds write access to this mutex is not clear to me. 

Passing to projects for their opinion on this.

The rest seems to be side effect of this:
* "Default RequestProcessor" thread gets blocked because of
"Module-Actions" thread: the "Module-Actions" thread is in
DataObjectPool.runAtomicAction()
* similarly "Settings Processor" requires read access on Registry
mutex, but "Default RequestProcessor" thread which modifies some
Registry values is holding the write acess on this mutex

So the question is who holds the write access on
ConfigurationManager.MUTEX? Or am I missing something?
Comment 4 Adam Sotona 2003-09-02 11:05:55 UTC
It looks like during Java template instantiation is fistly locked
DataObjectPool and then ConfigurationManager.
But my thread simply binds new settings to Context (that is the
ConfiguraionManager lock) and this action lately tries to lock
DataObjectPool (might be creation of new settings InstanceDataObject).

So deadlock is probably between template instantiation process and my
asynchronous Context.putObject() call.

Is there anything to be synchronized (inside core or in my code)?
Comment 5 Jesse Glick 2003-09-02 16:26:16 UTC
IMO likely to be an artifact of the use of old DS & Settings API as
the current Registry impl.
Comment 6 David Konecny 2003-10-13 14:01:12 UTC
I would suggest to fix issue 36347 instead (which blocks issue 35050).
That will resolve this problem.
Comment 7 Vitezslav Stejskal 2003-11-24 14:41:09 UTC
As described in
http://www.netbeans.org/servlets/ReadMsg?msgId=619519&listName=nbdiscuss
the current work on projects prototype has been stopped.
Comment 8 Jan Becicka 2003-11-25 13:46:55 UTC
Marking issue as VERIFIED --->
Comment 9 Jan Becicka 2003-11-25 13:51:27 UTC
---> CLOSED