Change of default owner.

Just happened to me again. Switched project group, and CPU goes into endless work:

"Opening projects" daemon prio=10 tid=0x092c0400 nid=0x3e50 runnable [0xaf718000]
   java.lang.Thread.State: RUNNABLE
	at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
	at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:228)
	at java.io.File.isDirectory(File.java:754)
	at java.io.File.toURI(File.java:661)
	at org.netbeans.modules.apisupport.project.queries.GlobalSourceForBinaryImpl.findSourceRoots(GlobalSourceForBinaryImpl.java:117)
	at org.netbeans.api.java.queries.SourceForBinaryQuery.findSourceRoots(SourceForBinaryQuery.java:90)
	at org.netbeans.modules.java.j2seplatform.platformdefinition.DefaultClassPathProvider$CompileClassPathImpl.getResources(DefaultClassPathProvider.java:623)
	at org.netbeans.api.java.classpath.ClassPath.entries(ClassPath.java:306)
	at org.netbeans.modules.java.source.classpath.CacheClassPath.getResources(CacheClassPath.java:118)
	at org.netbeans.api.java.classpath.ClassPath$SPIListener.propertyChange(ClassPath.java:1012)
	at org.openide.util.WeakListenerImpl$PropertyChange.propertyChange(WeakListenerImpl.java:188)
	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:276)
	at org.netbeans.modules.java.source.classpath.CacheClassPath.propertyChange(CacheClassPath.java:106)
	at org.openide.util.WeakListenerImpl$PropertyChange.propertyChange(WeakListenerImpl.java:188)
	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
	at org.netbeans.api.java.classpath.ClassPath.firePropertyChange(ClassPath.java:600)
	at org.netbeans.api.java.classpath.ClassPath$SPIListener.propertyChange(ClassPath.java:998)
	at org.openide.util.WeakListenerImpl$PropertyChange.propertyChange(WeakListenerImpl.java:188)
	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:276)
	at org.netbeans.modules.java.j2seplatform.platformdefinition.DefaultClassPathProvider$CompileClassPathImpl.pathsRemoved(DefaultClassPathProvider.java:686)
	at org.netbeans.api.java.classpath.GlobalPathRegistry.unregister(GlobalPathRegistry.java:257)
	at org.netbeans.modules.apisupport.project.NbModuleProject$OpenedHook.projectClosed(NbModuleProject.java:699)
	at org.netbeans.spi.project.ui.ProjectOpenedHook$1.projectClosed(ProjectOpenedHook.java:84)
	at org.netbeans.spi.project.ui.support.UILookupMergerSupport$OpenHookImpl.projectClosed(UILookupMergerSupport.java:205)
	at org.netbeans.spi.project.ui.ProjectOpenedHook$1.projectClosed(ProjectOpenedHook.java:84)
	at org.netbeans.modules.project.ui.OpenProjectList.notifyClosed(OpenProjectList.java:1117)
	at org.netbeans.modules.project.ui.OpenProjectList.access$1300(OpenProjectList.java:129)
	at org.netbeans.modules.project.ui.OpenProjectList$5.run(OpenProjectList.java:810)
	at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1369)
	at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1907)

I don't think it is related to bug 177799 - the stacktrace shows notifyClosed and that has not been modified. Can you generate some profiler snapshots when this happens again?

I thought I saw this happen again (similar thread dumps); I had recently closed a project group (was still scanning), then I opened a new project. Before I could attach a profiler the IDE finished, but this took much longer than it should have taken to open a new project. The log file showed around thirty blocks like this:

INFO [org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater]: Resolving dependencies took: 12 ms
INFO [org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater]: Complete indexing of 0 binary roots took: 0 ms
INFO [org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater]: Complete indexing of 0 source roots took: 0 ms (New or modified files: 0, Deleted files: 0) [Adding listeners took: 0 ms]
INFO [org.netbeans.modules.java.hints.WrongPackageSuggestion]: source cp is either null or does not contain the compiled source cp=

The thread dumps all have

...
	at org.netbeans.modules.java.source.classpath.CacheClassPath.getResources(CacheClassPath.java:133)
	at org.netbeans.api.java.classpath.ClassPath$SPIListener.propertyChange(ClassPath.java:1033)
	at org.openide.util.WeakListenerImpl$PropertyChange.propertyChange(WeakListenerImpl.java:193)
	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:276)
	at org.netbeans.modules.java.source.classpath.CacheClassPath.propertyChange(CacheClassPath.java:106)
	at org.openide.util.WeakListenerImpl$PropertyChange.propertyChange(WeakListenerImpl.java:193)
	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
	at org.netbeans.api.java.classpath.ClassPath.firePropertyChange(ClassPath.java:610)
	at org.netbeans.api.java.classpath.ClassPath$SPIListener.propertyChange(ClassPath.java:1019)
	at org.openide.util.WeakListenerImpl$PropertyChange.propertyChange(WeakListenerImpl.java:193)
	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:276)
	at org.netbeans.modules.java.j2seplatform.platformdefinition.DefaultClassPathProvider$CompileClassPathImpl.pathsRemoved(DefaultClassPathProvider.java:686)
	at org.netbeans.api.java.classpath.GlobalPathRegistry.unregister(GlobalPathRegistry.java:257)
...

May be a duplicate of #167965, I am not sure.

What was the memory situation when this happened? IDE had recently problems with memory management and when the memory is tight, everything is very slow and a lot of CPU is used. The dumps unfortunately do not contain this information. Thanks.

(In reply to comment #5)
> What was the memory situation when this happened?

Good question; I did not think to look at that. Next time it happens I will look at the heap used and its variance after GC.

Created attachment 98879 [details]
Thread dumps when switching project group; old projects closed, new projects never succeeded in being opened

Forgot to get a heap dump, sorry.

Again today. As usual, was switching project groups; all projects in the old group which were not in the new group were quickly removed from the Projects tab, leaving a project in both groups, but the projects only in the new group never appeared. Progress bar claimed "opening 10 projects...". Left it for several minutes before killing IDE (SIGTERM needed even after closing main window).

-Xmx512m as usual. Memory toolbar showed 485 limit, and heap in use varied between 187 and 315, with rapid allocation and collection. So I would not say that memory usage was tight in this circumstance; the heap usage seems to be driven by a real loop in processing, not vice versa.

Is it really necessary for java.source to do all this work synchronously when receiving events?

*** Bug 188272 has been marked as a duplicate of this bug. ***

*** Bug 196140 has been marked as a duplicate of this bug. ***

Not much common with java.source. And synchronous refresh of cache folders is desired (the classpath changes are used to fire ClassIndex events) and is probably not a problem. The problem is that there are two many event from DefaultClassPathProvider anyone listening on it will have the same problem.
I will try to fix the DFCP and we will see. It seems that you have a project or something in the closing project group which uses DefaultClassPath (has no CP).

I am trying to rewrite the DCPP to wait until closing (opening) of projects is done by using the Future got by OpenProjects.getDefault().openProjects(). Unfortunately the behavior of it is strange, I've expected to be blocked until the project group is switched or at least until the projects are closed (1 event) and until the new projects are opened (2 event). But I am getting 1000 of events. Jardo, what is the expected behavior? I am testing it using API support project which correctly registers the ClassPaths in ProjectOpenedHook (synchronously).

Fixed jet-main 9bcf681dfac5

Jesse, I was not able to reproduce it. So I am not able to verify.
I think it was somehow related to having opened non project java file while switching project groups.

Integrated into 'main-golden', will be available in build *201104020400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/9bcf681dfac5
User: Tomas Zezula <tzezula@netbeans.org>
Log: #182830:Endless loop closing project group