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.
Immediately after the IDE startup try to open all the projects (in my case 8 NB projects). It's reproducible. Product Version: NetBeans IDE Dev (Build 20080223222843) Java: 1.6.0_04; Java HotSpot(TM) Server VM 10.0-b19 System: Linux version 2.6.24-gentoo-r2 running on i386; UTF-8; cs_CZ (nb) I'll attach threaddump and screenshot.
Created attachment 57443 [details] screenshot
Created attachment 57444 [details] threaddump
changeset: 72563:9a20e49635e1 tag: tip user: Jaroslav Tulach <jtulach@netbeans.org> date: Wed Mar 12 14:03:26 2008 +0100 summary: Yet more logging to find the cause of 128692 Please simulate again with -J-Dorg.netbeans.modules.project.ui.OpenProjectList.level=0 and attach your log (as soon as the changeset propagates to the trunk).
*** Issue 129903 has been marked as a duplicate of this issue. ***
Created attachment 76932 [details] Screenshot from 090212
Just happened to me again (have seen this in the past on occasion). Of course I cannot reproduce, so the logging flag is no help; it also produces too much noise to be left on permanently. Perhaps the guilty code should somehow detect that lazy projects exist for too long (30 sec? I don't know) and automatically log a WARNING-level synopsis of the situation.
Can you inspect the node hierarchy when you see the problem again? Or generate a heap dump? That can tell us where the problem is. Thanks.
If it happens to me again I will try to get a heap dump. Not sure what you mean by inspecting the node hierarchy.
node hierarchy: Something like the old bean browser. Are filter nodes OK? Are original nodes OK? Are visualizers OK? I suspect the bug may not be in the ProjectRootNode at all or, it would be good to be sure
Tomáš just gave me a heapdump that clearly shows two BadgingNodes still delegate to LazyProject ones. E.g. this is not bug in nodes.
I know the problem is there, I just have no clue why it happens. I've just enhanced the logging a bit: core-main#4bcbfd0e4386 all messages from the OpenProjectsList are collected. After the open is finished, I do check for LazyProject still being in lookup and if it is there and if so, I print all the collected log. Reopen with the newly generated log. Thanks.
Integrated into 'main-golden', will be available in build *200903170201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/4bcbfd0e4386 User: Jaroslav Tulach <jtulach@netbeans.org> Log: Hunt for cause of #128692 - collecting logging and in case LazyProject stays visible, reporting all that have been collected.
Needs the log level for OpenProjectList really to be set to FINEST in the code? I need to log other things during project opening and the output is cluttered by OpenProjectList log, which cannot be turned off without recompiling projectui.
I already complained to jtulach about the excess logging; he said we would try to fix it.
core-main#1f74053488c5
Integrated into 'main-golden', will be available in build *200903191401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/1f74053488c5 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #128692: Collecting messages into StringBuffer rather then own log Handler
Reproduced in: Product Version: NetBeans IDE Dev (Build 090420) Java: 1.5.0_16; Java HotSpot(TM) 64-Bit Server VM 1.5.0_16-b02 System: Linux version 2.6.27-11-generic running on amd64; UTF-8; cs_CZ (nb) Attaching IDE log...
Created attachment 80592 [details] IDE log
Nice. Looks like call to supportCh.firePropertyChange does not end up in BadgingNode in spite the node adds a listener in constructor.
core-main#87d6c7ab5ce9
Integrated into 'main-golden', will be available in build *200904220201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/87d6c7ab5ce9 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #128692: Test to simulate that projects are opened sooner than the BadgingNode adds its listener
I think you should consider backing out 1f74053488c5 now; I am getting stack traces like this, showing that the logging is performing nontrivial work: at org.openide.util.EditableProperties.cloneProperties(EditableProperties.java:339) at org.netbeans.spi.project.support.ant.EditableProperties.cloneProperties(EditableProperties.java:217) at org.netbeans.spi.project.support.ant.ProjectProperties.getProperties(ProjectProperties.java:115) at org.netbeans.spi.project.support.ant.AntProjectHelper$5.run(AntProjectHelper.java:707) at org.netbeans.spi.project.support.ant.AntProjectHelper$5.run(AntProjectHelper.java:705) at org.openide.util.Mutex.readAccess(Mutex.java:285) at org.netbeans.spi.project.support.ant.AntProjectHelper.getProperties(AntProjectHelper.java:705) at org.netbeans.modules.mobility.project.J2MEProject.toString(J2MEProject.java:1225) at java.lang.String.valueOf(String.java:2615) at java.util.AbstractCollection.toString(AbstractCollection.java:454) at java.util.Collections$UnmodifiableCollection.toString(Collections.java:1003) at java.lang.String.valueOf(String.java:2615) at java.lang.StringBuilder.append(StringBuilder.java:116) at org.openide.util.lookup.SimpleLookup.toString(SimpleLookup.java:82) at java.lang.String.valueOf(String.java:2615) at java.util.AbstractCollection.toString(AbstractCollection.java:454) at java.lang.String.valueOf(String.java:2615) at java.lang.StringBuilder.append(StringBuilder.java:116) at org.openide.util.lookup.ProxyLookup.toString(ProxyLookup.java:91) at java.lang.String.valueOf(String.java:2615) at java.util.AbstractCollection.toString(AbstractCollection.java:454) at java.lang.String.valueOf(String.java:2615) at java.lang.StringBuilder.append(StringBuilder.java:116) at org.openide.util.lookup.ProxyLookup.toString(ProxyLookup.java:91) at java.lang.String.valueOf(String.java:2615) at java.lang.StringBuffer.append(StringBuffer.java:220) at org.netbeans.modules.project.ui.OpenProjectList.printMsg(OpenProjectList.java:165) at org.netbeans.modules.project.ui.OpenProjectList.log(OpenProjectList.java:154) at org.netbeans.modules.project.ui.ProjectsRootNode$BadgingNode.replaceProject(ProjectsRootNode.java:554) at org.netbeans.modules.project.ui.ProjectsRootNode$BadgingNode.access$000(ProjectsRootNode.java:428) at org.netbeans.modules.project.ui.ProjectsRootNode.checkNoLazyNode(ProjectsRootNode.java:209) at org.netbeans.modules.project.ui.OpenProjectList$LoadOpenProjects.run(OpenProjectList.java:318) (834f725a5b5a is a contributing factor in that case.)
This particular problem is fixed in core-main#9635d330ddd2 I'd rather leave the logging on to have some info if similar problem re-appears. But if the logging causes problems, it can of course be removed or made conditional.
That should help. BTW after my last comment I also simplified J2MEProject.toString to not include the project properties.
Integrated into 'main-golden', will be available in build *200908130201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/9635d330ddd2 User: Jaroslav Tulach <jtulach@netbeans.org> Log: Tweak to #128692 - don't log content of BadgingLookup