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 46820 - Deadlock during opening project by org.netbeans.junit.ide.ProjectSupport.openProject
Summary: Deadlock during opening project by org.netbeans.junit.ide.ProjectSupport.open...
Status: CLOSED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 4.x
Hardware: All All
: P1 blocker (vote)
Assignee: Jan Becicka
URL:
Keywords: T9Y, THREAD
Depends on:
Blocks:
 
Reported: 2004-08-02 10:36 UTC by Marian Mirilovic
Modified: 2007-09-26 09:14 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Full thread-dump (17.44 KB, text/plain)
2004-08-02 10:37 UTC, Marian Mirilovic
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marian Mirilovic 2004-08-02 10:36:58 UTC
[nb_dev](200408011800), [jdk1.5.0](b58)

In our performance tests we open three projects,
first by property provided by xtest is opened
directly after start, second one we open by method
org.netbeans.junit.ide.ProjectSupport.openProject

and it never finishes! After 20 minutes the IDE is
killed by xtest and I'll attach thread-dump.

When I tried do the same by hands it works fine.

This is reproducible on tested platforms : Win2K,
WinXP, JDS2 (only Sol9 works fine;) )

I don't say mdr is responsible (possibly projects,
xtest or junit) , so feel free to reasigne.

Just to know, mentioned test is setup for all
other performance tests, means is too important
for performance test infrastrucuture.
Comment 1 Marian Mirilovic 2004-08-02 10:37:22 UTC
Created attachment 16598 [details]
Full thread-dump
Comment 2 Jiri Skrivanek 2004-08-02 12:11:00 UTC
Is there a specific build when it started happened?
Comment 3 Marian Mirilovic 2004-08-02 12:24:11 UTC
It started in builds ~20-21 july ....
Comment 4 Jesse Glick 2004-08-02 12:55:20 UTC
javacore.RepositoryUpdater.fileFolderCreated is at fault for
attempting to acquire new locks or otherwise block from within a
listener callback method.

Anyway it's pretty stupid since the file which was created -
$projdir/nbproject/private/private.properties - is not on any source
path and is totally irrelevant to the JMI database.
Comment 5 Jan Becicka 2004-08-02 13:39:39 UTC
RepositoryUpdater.java (in directory
D:\sources\trunk\java\javacore\src\org\netbeans\modules\javacore\)
Checking in Util.java;
/cvs/java/javacore/src/org/netbeans/modules/javacore/Util.java,v  <--
 Util.java
new revision: 1.5; previous revision: 1.4
done
Checking in RepositoryUpdater.java;
/cvs/java/javacore/src/org/netbeans/modules/javacore/RepositoryUpdater.java,v
 <--  RepositoryUpdater.java
new revision: 1.15; previous revision: 1.14
done
Comment 6 Marian Mirilovic 2004-08-11 10:08:58 UTC
verified in [nb_dev](200408101800)
Comment 7 Quality Engineering 2007-09-20 09:44:43 UTC
Reorganization of java component