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
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
Created attachment 90759 [details]
This issue already has 24 duplicates
dafe can you look at this one please?
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.
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.
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.
fixed in 1281281b08ef