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 36749 - [2003-10-22]Deadlock during startup
Summary: [2003-10-22]Deadlock during startup
Status: VERIFIED FIXED
Alias: None
Product: javaee
Classification: Unclassified
Component: HTTP Monitor (show other bugs)
Version: 3.x
Hardware: Sun SunOS
: P2 blocker (vote)
Assignee: Ana.von Klopp
URL:
Keywords: THREAD
Depends on:
Blocks: 35833
  Show dependency tree
 
Reported: 2003-10-22 13:48 UTC by Jan Lahoda
Modified: 2004-02-23 11:58 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Two full thread dumps of the deadlock. (24.01 KB, text/plain)
2003-10-22 13:50 UTC, Jan Lahoda
Details
Links to diffs (506 bytes, text/plain)
2003-11-14 01:09 UTC, Ana.von Klopp
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Lahoda 2003-10-22 13:48:35 UTC
WS-v2 build 031022, JDK1.4.2.

Deadlock occurs sometimes during startup.
The userdir was the same as used for issue #36745.
I have archived it, so I can attach it if necessary.
The full thread dumps are attached to this issue.

Special info: first time the deadlock occured, I
tested -XX:CompileThreshold=2 setting (the
deadlock later occured even without this setting).
Comment 1 Jan Lahoda 2003-10-22 13:50:00 UTC
Created attachment 11936 [details]
Two full thread dumps of the deadlock.
Comment 2 Peter Zavadsky 2003-10-22 14:04:20 UTC
Note: It in new winsys build.

Assigning to Yarda. Please have a look at it and assign where the
problem is.
Comment 3 Jaroslav Tulach 2003-10-22 16:06:43 UTC
It could be possible to break the deadlock by not creating node
structure in constructor of MonitorAction or by not instantiating
monitor action or the controler at all.

Comment 4 Ana.von Klopp 2003-11-13 17:56:43 UTC
I will look into changing the behaviour. 
Comment 5 Ana.von Klopp 2003-11-14 00:25:20 UTC
I looked into the problem and realized that Jesse Glick had modified 
the files that load the transactions a couple of months ago with 
respect to how the nodes are created. These modifications introduced 
the Mutex code which apparently causes the hang now. There are 
numerous other problems associated with this change (which ought to 
have been obvious if the component had been tested at all afterwards - 
for example saving did not work). I'm backing out these changes for 
now (the component will be rewritten to use Looks as soon as I have 
time). 

I removed the creation of the nodes when the action is created anyway, 
since it's not necessary to do it on startup. 
Comment 6 Ana.von Klopp 2003-11-14 01:09:01 UTC
Created attachment 12156 [details]
Links to diffs
Comment 7 Jesse Glick 2003-11-14 11:22:55 UTC
May need to be re-fixed as part of issue #35833, TBD - the use of
Mutex.EVENT was preventing critical non-thread-safe Node methods from
being called from arbitrary threads due to abuse of Node/Children as a
data model. Underlying problem will need some fix for promo-B.
Comment 8 L Martinek 2004-02-23 11:58:47 UTC
verified