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 55398 - Deadlock on startup
Summary: Deadlock on startup
Status: CLOSED FIXED
Alias: None
Product: javaee
Classification: Unclassified
Component: Code (show other bugs)
Version: 4.x
Hardware: PC Linux
: P2 blocker (vote)
Assignee: Pavel Fiala
URL:
Keywords: THREAD
: 54876 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-02-23 10:10 UTC by _ rkubacki
Modified: 2006-03-24 10:28 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
thread dump (18.56 KB, text/plain)
2005-02-23 10:11 UTC, _ rkubacki
Details
packaged testuserdir and apps (276.85 KB, application/octet-stream)
2005-02-23 10:19 UTC, _ rkubacki
Details

Note You need to log in before you can comment on or make changes to this bug.
Description _ rkubacki 2005-02-23 10:10:52 UTC
dev build from sources snapshot from Feb 22. JDK
5.0u1, Linux.

I have a testuserdir with j2ee project containing
ejb & web modules and some other modules. The
editor has an open file with EJB bussines method
and some node under ejb module is probably
selected in project expolorer.

There is a deadlock on startup. Folder instance,
RP and maybe AWT thread are involved.
Comment 1 _ rkubacki 2005-02-23 10:11:59 UTC
Created attachment 20467 [details]
thread dump
Comment 2 _ rkubacki 2005-02-23 10:19:37 UTC
Created attachment 20468 [details]
packaged testuserdir and apps
Comment 3 _ rkubacki 2005-02-23 13:26:54 UTC
BTW: Petr N. has some observations about this. You might want to
discuss it with him.
Comment 4 Petr Nejedly 2005-02-23 13:50:14 UTC
Out Mutex has no policy to avoid starvation and that is exactly what
happened in this case:
-) Thread A has a readAccess and waits for somebody else*
-) Thread B wants writeAccess so it is queued
-) Thread C then asks for readAccess, but because B is already waiting,
   it is queued as well.
-) Thread A is starved because it waits for thread C

*) This alone is not nice. Waiting for somebody while holding a
precious lock.

On one hand, if the Mutex was smart enough, it could grant the read
request as the write requestor still sleeps.

On the other hand, that could cause number of different starvation
situations as any writer could be left sleeping at the end of the
queue while readers keep lending the mutex to each other.
Comment 5 Jaroslav Tulach 2005-02-24 08:20:35 UTC
The common approach to solving deadlocks is the split the locks into
hierarchy and allow only acquiring locks just in predefined order.
This shall be considered in the fix of this problem as well.

In NetBeans the lowest system is filesystem, then there are
datasystems and later there are nodes. It should not happen that work
required on datasystem level needs to wait for something to be done in
nodes.

That is why I think j2ee guys should change the
org.netbeans.modules.j2ee.ddloaders.multiview.EjbJarMultiViewDataObject.parse(EjbJarMultiViewDataObject.java:457)
org.netbeans.modules.j2ee.ddloaders.multiview.EjbJarMultiViewDataObject.createModelFromFileObject(EjbJarMultiViewDataObject.java:417)
       
org.netbeans.modules.xml.multiview.XmlMultiViewDataObject.<init>(XmlMultiViewDataObject.java:62)
org.netbeans.modules.j2ee.ddloaders.multiview.EjbJarMultiViewDataObject.<init>(EjbJarMultiViewDataObject.java:97)
org.netbeans.modules.j2ee.ddloaders.ejb.EjbJarDataLoader.createMultiObject(EjbJarDataLoader.java:94)
org.openide.loaders.MultiFileLoader.handleFindDataObject(MultiFileLoader.java:73)
code to not create any node. 

The rule is do not do any (unnecessary) work in data object's constructor.

Comment 6 Milan Kuchtiak 2005-02-25 10:29:28 UTC
I will look at the issue. I think I'll be able to fix that.
Comment 9 Pavel Fiala 2005-02-28 10:31:34 UTC
*** Issue 54876 has been marked as a duplicate of this issue. ***
Comment 10 Jan Horvath 2005-04-06 11:33:46 UTC
v.