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 162612 - 100% CPU after starting to open a Maven project but then stopping
Summary: 100% CPU after starting to open a Maven project but then stopping
Alias: None
Product: projects
Classification: Unclassified
Component: Maven (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Milos Kleint
Depends on: 163295 210465
  Show dependency tree
Reported: 2009-04-14 17:20 UTC by Jesse Glick
Modified: 2012-03-30 22:09 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

Attempted patch; cancel() is called on PCA.MU, but perhaps something else swallows thread interrupt status (6.13 KB, patch)
2009-04-14 17:22 UTC, Jesse Glick
Details | Diff
Log & thread dumps (83.25 KB, text/plain)
2009-04-14 17:23 UTC, Jesse Glick
More thread dumps (128.81 KB, text/plain)
2009-04-17 17:28 UTC, Jesse Glick

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2009-04-14 17:20:48 UTC
090413. File > Open Project. Select hudson/trunk/main/core but do not click Open, click Cancel instead. CPU goes to 100%
and stays there for at least several minutes (I never waited to see if it would eventually stop). IDE must be shut down
to become usable again.

I will attach some typical thread dumps - maven.SubprojectProviderImpl is active - plus an patch which attempted to
cancel the process but which did not seem to work.
Comment 1 Jesse Glick 2009-04-14 17:22:15 UTC
Created attachment 80058 [details]
Attempted patch; cancel() is called on PCA.MU, but perhaps something else swallows thread interrupt status
Comment 2 Jesse Glick 2009-04-14 17:23:52 UTC
Created attachment 80059 [details]
Log & thread dumps
Comment 3 Milos Kleint 2009-04-16 07:53:02 UTC
I've also noticed that selecting a project in the Open project dialog can produce an effect of slow response. Even
though the project loading is done in non-awt thread. Maybe it needs to be delayed a bit, and rescheduled if selection
changes often. The interrupt is probably swallowed by the method that loads the maven project instance. 

I'll look into it.
Comment 4 Milos Kleint 2009-04-16 12:40:32 UTC
integrated, the cancelling seemed to work for me.
Comment 5 Quality Engineering 2009-04-17 08:38:32 UTC
Integrated into 'main-golden', will be available in build *200904170201* on (upload may still be in progress)
User: Milos Kleint <>
Log: #162612 delay loading of display name a bit for improved scrolling perfomance, allow cancelling the job.
also for mavenprojects allow cancelling the getsubprojects routine to skip unnecessary executions and project loadings..
Comment 6 Jesse Glick 2009-04-17 17:28:27 UTC
I'm afraid it's still reproducible for me in 47e7f2710e5d which includes the attempted fix. Will attach some thread dumps.

My suspicion is that the thread does get interrupted and some process is ended, but then something else starts a new
blocking process. If true, a proper fix might require RequestProcessor.Task.cancel to be more aggressive and keep on
interrupting the thread until it really dies.
Comment 7 Jesse Glick 2009-04-17 17:28:41 UTC
Created attachment 80379 [details]
More thread dumps
Comment 8 Jesse Glick 2009-04-17 17:31:13 UTC
P2 is justified if this happens to anyone besides me (still not sure what the true trigger is); it is impossible to open
any Maven project using Open Project unless you are willing to restart the IDE right afterwards. I have been using
--open on the CLI, Open Project context menu item in Favorites, etc. to avoid hitting this bug. Seems to be a recent
regression because I do not recall having such issues in the past.
Comment 9 Jesse Glick 2009-04-20 23:04:37 UTC
Again in bca1f4cb6e3b. BTW I encounter these issues working with Hudson sources.

"org.netbeans.modules.project.ui.ProjectChooserAccessory$ModelUpdater" daemon prio=10 tid=0xae434c00 nid=0x7f3a runnable
   java.lang.Thread.State: RUNNABLE
	at org.apache.maven.project.interpolation.RegexBasedModelInterpolator.interpolate(
	at org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(
	at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(
	at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(
	at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(
	at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(
	at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(
	at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(
	at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(
	at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(
	at org.netbeans.modules.maven.embedder.NbArtifactResolver.resolveTransitively(
	at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(
	at org.apache.maven.plugin.DefaultPluginManager.getPluginArtifacts(
	at org.apache.maven.plugin.DefaultPluginManager.addPlugin(
	at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(
	at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(
	at org.apache.maven.extension.DefaultExtensionManager.addPluginAsExtension(
	at org.netbeans.modules.maven.embedder.NbExtensionManager.addPluginAsExtension(
	at org.apache.maven.extension.DefaultBuildExtensionScanner.scanInternal(
	at org.apache.maven.extension.DefaultBuildExtensionScanner.scanForBuildExtensions(
	at org.apache.maven.embedder.MavenEmbedder.readProject(
	at org.apache.maven.embedder.MavenEmbedder.readProjectWithDependencies_aroundBody0(
	at org.apache.maven.embedder.MavenEmbedder.readProjectWithDependencies_aroundBody1$advice(
	at org.apache.maven.embedder.MavenEmbedder.readProjectWithDependencies(
	at org.netbeans.modules.maven.NbMavenProjectImpl.getOriginalMavenProject(
	- locked <0x72d28cc0> (a org.netbeans.modules.maven.NbMavenProjectImpl)
	at org.netbeans.modules.maven.NbMavenProjectImpl.<init>(
	at org.netbeans.modules.maven.NbMavenProjectFactory.loadProject(
	at org.netbeans.api.project.ProjectManager.createProject(
	at org.netbeans.api.project.ProjectManager.access$300(
	at org.netbeans.api.project.ProjectManager$
	at org.netbeans.api.project.ProjectManager$
	at org.openide.util.Mutex.readAccess(
	at org.netbeans.api.project.ProjectManager.findProject(
	at org.netbeans.modules.maven.SubprojectProviderImpl.processOneSubproject(
	at org.netbeans.modules.maven.SubprojectProviderImpl.addProjectModules(
	at org.netbeans.modules.maven.SubprojectProviderImpl.addProjectModules(
	at org.netbeans.modules.maven.SubprojectProviderImpl.getSubprojects(
	at org.netbeans.modules.project.ui.ProjectChooserAccessory$ModelUpdater.addSubprojects(
	at org.netbeans.modules.project.ui.ProjectChooserAccessory$
	at org.openide.util.RequestProcessor$
	at org.openide.util.RequestProcessor$
Comment 10 Jesse Glick 2009-04-24 00:14:32 UTC
I should mention that if you wait long enough, it does eventually quiet down, but this can take several minutes. If I am
running on battery power I usually do not have the patience. :-)
Comment 11 Milos Kleint 2009-04-24 07:44:10 UTC
do you use mouse or keyboard to navigate? is the project you open an aggregating one? (with modules)

The issue was first about cancelling the open dialog, now you mention various ways to open a project.. 

There's nothing wrong with the stacktrace, just loading subprojects. I suppose you keep triggering the loading of the
subprojects of the complete set of hudson projects, I don't, when I open the core project. I guess we have different
ways of using the dialog.

Comment 12 Jesse Glick 2009-04-24 15:11:02 UTC
Using keyboard, quickfilechooser. hudson/trunk does get momentarily selected as I use code completion to move into
subdirs; maybe hudson/trunk/plugins is the problem. But the project chooser is supposed to stop loading subprojects when
you move on to another project selection or close the dialog.
Comment 13 Milos Kleint 2009-05-12 07:58:08 UTC
BTW: I've figured out some performance optimizations in the last weeks that should significantly reduce the time for
loading projects in batches (eg. when loading subprojects)
Comment 14 Jesse Glick 2009-07-07 15:05:07 UTC
Reproduced in 090707 (cluster.config=full), not using quickfilechooser. Opened .../hudson/trunk/plugins/mercurial using
standard directory chooser (keyboard only). Heavy CPU, and I saw some exceptions in the log about plugins/perforce,
indicating that the IDE was loading every plugin project.

Maybe need SubprojectProvider2 which would return some kind of cancellable future object?
Comment 15 Milos Kleint 2009-07-20 14:50:00 UTC
as long as you traverse from top directory into the child dirs, all the project dirs on the way get loaded with all
their children. Sort of constraint of the chooser dialog's accessory.. If it were not loading subprojects, we would be
Comment 16 Antonin Nebuzelsky 2010-07-30 15:17:11 UTC
Reassigning to default owner.
Comment 17 Antonin Nebuzelsky 2010-08-12 13:01:55 UTC
Tested by selecting hudson, hudson/main and hudson/main/core with build 100812-174de290da8c, but saw the thread active only for a few seconds.

Cannot reproduce the heavy CPU use for the reported long time.
Comment 18 Jesse Glick 2010-08-12 18:37:38 UTC
(In reply to comment #17)
> Tested by selecting hudson, hudson/main and hudson/main/core

Try navigating through hudson/trunk/plugins/, and try using quickfilechooser as well as standard dirchooser.
Comment 19 Quality Engineering 2011-07-27 14:07:50 UTC
Integrated into 'main-golden'
User: Jesse Glick <>
Log: Refining #65349 implementation of asynch project open to better support large source trees.
- show meaningful messages in the progress handle, and make it cancelable
- do not show a blocking modal dialog
- permit subproject calculation to be interrupted when supported (#162612)
Comment 20 Milos Kleint 2012-03-30 13:05:44 UTC
what is there more to do?

I've tried with jenkins source, unfortunately it includes the plugins sources no more. same operation with maven/plugins makes it clear that all plugin's MavenProject instances are loaded via the plugins/ folder selection, happens both with quickfilechooser and regular chooser when using keyboard. 

the CPU utilization is a function of number of projects, complexity of the project (number of parents, dependencies, plugins). 2.1 vs current 3.x embedder is also a factor in the equation.
Comment 21 Jesse Glick 2012-03-30 22:09:32 UTC
A fix of bug #210465 would I guess render this obsolete - submodules would be scanned for only if the user explicitly requested this, say with a context menu item, but not just from selecting the root of the reactor in Open Project.

A new SPI could also provide an explicit Cancellable object that would be more reliable than thread interrupted status.