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.
Summary: | [2003-10-22]Deadlock during startup | ||
---|---|---|---|
Product: | javaee | Reporter: | Jan Lahoda <jlahoda> |
Component: | HTTP Monitor | Assignee: | Ana.von Klopp <avk> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | jglick, pnejedly |
Priority: | P2 | Keywords: | THREAD |
Version: | 3.x | ||
Hardware: | Sun | ||
OS: | SunOS | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 35833 | ||
Attachments: |
Two full thread dumps of the deadlock.
Links to diffs |
Description
Jan Lahoda
2003-10-22 13:48:35 UTC
Created attachment 11936 [details]
Two full thread dumps of the deadlock.
Note: It in new winsys build. Assigning to Yarda. Please have a look at it and assign where the problem is. 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. I will look into changing the behaviour. 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. Created attachment 12156 [details]
Links to diffs
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. verified |