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.
Product Version: NetBeans IDE Dev (Build 201101200001) Java: 1.6.0_22; Java HotSpot(TM) 64-Bit Server VM 17.1-b03-307 System: Mac OS X version 10.5.8 running on x86_64; MacRoman; en_US (nb) Userdir: /Applications/NetBeans/userdirs/7.0-20110120 This dialog appears very often when trying to use the hints, insert code and fix imports dialogs. For example on a very simple session bean with 1 method. The IDE log displays the following output: WARNING [org.netbeans.modules.progress.ui.RunOffEDTImpl]: Lengthy operation: org.netbeans.modules.editor.codegen.NbGenerateCodeAction$1:63,858:5:17,576:12771.60 WARNING [org.netbeans.modules.progress.ui.RunOffEDTImpl]: Lengthy operation: org.netbeans.modules.editor.codegen.NbGenerateCodeAction$1:75,126:6:17,576:12521.00 WARNING [org.netbeans.modules.progress.ui.RunOffEDTImpl]: Lengthy operation: org.netbeans.modules.editor.codegen.NbGenerateCodeAction$1:86,556:7:17,576:12365.14 WARNING [org.netbeans.modules.parsing.impl.TaskProcessor]: ParserManager.parse called in AWT event thread by: org.netbeans.modules.web.project.WebEMGenStrategyResolver.isInjectionTarget(WebEMGenStrategyResolver.java:109) WARNING [org.netbeans.modules.parsing.impl.TaskProcessor]: ParserManager.parse called in AWT event thread by: org.netbeans.modules.web.beans.impl.model.WebBeansModelImplementation.runReadAction(WebBeansModelImplementation.java:100) WARNING [org.netbeans.modules.parsing.impl.TaskProcessor]: ParserManager.parse called in AWT event thread by: org.netbeans.modules.j2ee.dd.impl.ejb.annotation.EjbJarMetadataModelImpl.runReadAction(EjbJarMetadataModelImpl.java:94) WARNING [org.netbeans.modules.parsing.impl.TaskProcessor]: ParserManager.parse called in AWT event thread by: org.netbeans.modules.j2ee.persistence.action.EntityManagerGenerator.generate(EntityManagerGenerator.java:171) Adding a fold that is identical with another previously added fold from the same FoldManager is not allowed. Existing fold: [code-block] E1 <544,579>, desc='{...}', hash=0x1c7c0115, [545, 578] {545, 578}; FoldManager: org.netbeans.modules.java.editor.fold.JavaElementFoldManager@28e2ea1e New fold: [code-block] E1 <544,579>, desc='{...}', hash=0x49786c8a, [545, 578] {545, 578}; FoldManager: org.netbeans.modules.java.editor.fold.JavaElementFoldManager@28e2ea1e WARNING [org.netbeans.modules.progress.ui.RunOffEDTImpl]: Lengthy operation: org.netbeans.modules.java.editor.imports.JavaFixAllImports$2:78,930:3:53,533:26310.00 WARNING [org.netbeans.modules.progress.ui.RunOffEDTImpl]: Lengthy operation: org.netbeans.modules.java.editor.imports.JavaFixAllImports$2:90,636:4:53,533:22659.00
Created attachment 105301 [details] messages.log attaching messages log file
bumping priority up to p2 because this really makes a lot of functionality such as hints and fix imports unusable for me. The workaround seems to be to type or paste some code, then wait 5 or 10 minutes, then fix imports, which is extremely inconvenient
I rarely see the dialog (normally only in case the IDE is swapped off, or is scanning is running). Could you please generate some profile me snapshots so that we can see what is taking the time? Thanks. http://wiki.netbeans.org/FitnessViaPartnership
Created attachment 106718 [details] profiler snapshot when lenght operation dialog appears adding profiler snapshot
Thanks for the snapshot. The problem is quite clear now: the TreeLoader tries to load javadoc for a class using JavadocHelper.getJavadoc(Element). This method itself may still do a network connection. If this network connection fails after a significant amount of time, which is what seems to happen in Ken's case, the JavadocHelper will try this connection each time again, each time taking the time to fail. I personally do not see a different solution than to allow disabling of the remote Javadoc on JavadocHelper.getJavadoc level: http://hg.netbeans.org/jet-main/rev/81a128e62b1e
Tomas worked on this most recently I think. Fix seems reasonable; remote Javadoc is intended for viewing but should not be used for obtaining method parameter names and the like (unless perhaps a cache is implemented). Better would be if -g:vars were used when compiling important APIs, I guess. Can java.source retrieve param names from bytecode where present?
I was fixing the code completion. This problem is a bit different, the http request is done from TreeLoader before the tree loader gets the TextStream to be able to check if it's remote.
Integrated into 'main-golden', will be available in build *201103090000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/81a128e62b1e User: Jan Lahoda <jlahoda@netbeans.org> Log: #194653: really disabling remote javadoc in TreeLoader.
*** Bug 196788 has been marked as a duplicate of this bug. ***
I'm afraid I'm still seeing this in Product Version: NetBeans Platform Dev (Build 201103120400) Java: 1.6.0_24; Java HotSpot(TM) 64-Bit Server VM 19.1-b02-334 System: Mac OS X version 10.6.6 running on x86_64; MacRoman; es_ES (test) Userdir: /Users/antonio/.netbeans/dev A stack trace available at http://netbeans.org/bugzilla/show_bug.cgi?id=196788
Case from http://netbeans.org/bugzilla/show_bug.cgi?id=196788 fixed in jet-main. http://hg.netbeans.org/jet-main/rev/d3285b4c63ea
*** Bug 194017 has been marked as a duplicate of this bug. ***