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 176474

Summary: AWT thread blocked for 16047 ms.
Product: projects Reporter: ravindranathakila <ravindranathakila>
Component: MavenAssignee: David Simonek <dsimonek>
Status: VERIFIED FIXED    
Severity: normal CC: mkleint, _m4c0_
Priority: P2 Keywords: PERFORMANCE
Version: 6.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter: 157710
Attachments: nps snapshot

Description ravindranathakila 2009-11-10 19:58:05 UTC 
Build: NetBeans IDE 6.8 Beta (Build 200910212001)
VM: Java HotSpot(TM) Client VM, 14.2-b01, Java(TM) SE Runtime Environment, 1.6.0_16-b01
OS: Windows XP, 5.1, x86

User Comments:
jtulach: Enter on a successful test in Test Results view

matusdekanek: profiling maven project (web, monitoring profiling task, threads monitoring enabled, running on glassfish)
on monitoring threads window, switching the view from fixed scale to 'fit to' scale

GUEST: Damn. That was a long one. I run a Maven build and it failed all the tests. So I clicked on the text link that tells me this so I can see the details of the failure (ie. the strack traces).

vargas: Opening a dependency graph in a small project (just a few classes, one jsp, one jpa entity)

GUEST: clicking around ...

alexismp: Tried to select a source tab while building Maven dependency graph


Maximum slowness yet reported was 1500296 ms, average is 71552
Comment 1 ravindranathakila 2009-11-10 19:58:09 UTC 
Created attachment 90759 [details]
nps snapshot
Comment 2 Exceptions Reporter 2009-11-10 19:58:15 UTC 
This issue already has 24 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=157710
Comment 3 Milos Kleint 2009-11-10 23:43:50 UTC 
dafe can you look at this one please?
Comment 4 David Simonek 2009-11-11 10:18:38 UTC 
My evaluation so far:
Profiler logs contain several situations. Most common and dangerous is when NbMavenProjectImpl$Info.getDisplayName() is called (in EQ thread) when loading of other project or reloading of the same project occurs at the same time (outside EQ, of course). Then EQ thread is blocked waiting, as getDisplayName can end in NbMavenProjectImpl.getOriginalMavenProject, which somehow waits for NbMavenProjectImpl.loadMavenProject.

Typical example is that during maven execution (project build, run), project is asked for its display name. I can't recognize from snapshots if it's the same project or different one.
Comment 5 Milos Kleint 2009-11-12 00:18:55 UTC 
NbMavenProjectImpl.getOriginalMavenProject should currently only block on the first, initial load of the project and be cached from then on. Any subsequent refreshes of the model (after build, on user action) will first load the project off AWT (and keep serving the old content) and only when finished quickly replace the cached value.
AFAIK the method should allow loading projects concurently, there is no lock across projects (unless there is something within the maven internals that gets synced and becomes the bottleneck)

the first loading of the project should always happen on background for opened projects, the risky group are the projects that are non opened but somehow used. The appearing bottlenecks and inevitable there. maven3 might help there in terms of speeding up the process of loading.
Comment 6 David Simonek 2009-11-12 06:10:27 UTC 
We hopefully found main reason of blocking: NbMavenProjectImpl.getOriginalMavenProject and NbMavenProjectImpl.loadMavenProject share the same lock (both are synchronized) but loadMavenProject needn't to be, as it loads and returns alternate instance of MavenProject and doesn't touch instance data. Thanks mkleint for assistance.

Btw reports also include other issue, clicking on test link in output window can froze system for a while, I will create separate issue for that problem.
Comment 7 David Simonek 2009-11-12 06:28:42 UTC 
fixed in 1281281b08ef
Comment 8 Jaroslav Pospisil 2009-11-18 07:50:58 UTC 
v.