Bug 176474 - AWT thread blocked for 16047 ms.
AWT thread blocked for 16047 ms.
Status: VERIFIED FIXED
Product: projects
Classification: Unclassified
Component: Maven
6.x
All All
: P2 (vote)
: 6.x
Assigned To: David Simonek
issues@projects
EXCEPTIONS_REPORT perf-profileme
: PERFORMANCE
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-10 19:58 UTC by ravindranathakila
Modified: 2009-11-18 07:50 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
nps snapshot (256.00 KB, application/nps)
2009-11-10 19:58 UTC, ravindranathakila
Details

Note You need to log in before you can comment on or make changes to this bug.
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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo