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.
This issue was reported manually by pjiricka. It already has 2 duplicates Build: NetBeans IDE Dev (Build web-main-3385-on-100618) VM: Java HotSpot(TM) 64-Bit Server VM, 16.3-b01-279, Java(TM) SE Runtime Environment, 1.6.0_20-b02-279-9M3165 OS: Mac OS X User Comments: tnleeuw: Code completion in Java. Previously there was slow AWT response after opening a Java file and trying to close a node in the Project tree. pjiricka: Navigating in Javadoc inside the code completion documentation window, for remote Javadoc. Maximum slowness yet reported was 6324 ms, average is 5109
Created attachment 100299 [details] nps snapshot
Created attachment 101086 [details] AWT event queue stack trace I am attaching another case where remote Javadoc is accessed from AWT event queue.
Either NbGenerateCodeAction.actionPerformed should run asynch, or TreeLoader.getParamNamesFromJavadocText should skip remote URLs.
Jesse, this bug is assigned to you intentionally, or by accident? Do you plan to fix it?
Assigned to me since I implemented the HTTP Javadoc support. I don't know yet if I will get to it in 7.0.
*** Bug 191177 has been marked as a duplicate of this bug. ***
The stack trace should be fixed by bug #191914. Other snapshots may be different issues.
Created attachment 103932 [details] nps snapshot alt+inser in a java class.
Created attachment 104298 [details] nps snapshot pressed "alt+inser" in an 20 lines class extending Exception
*** Bug 193386 has been marked as a duplicate of this bug. ***
#20110117 Big performance problem from my point of view, CC window did not display on my mac at all (i.e. i took > 15s) Finally from selfprofiler i was able to find root cause - reading remote javadoc. IMO this affects all mac user in very significant way, loading of remote javadoc should not block CC. At least there is now a possibility to remove default javadoc (#191914)
Snapshots from exception reporter look to be mixing two unrelated things. Probably Version should really be 7.0 but I don't know.
core-main #4fe3904e507a
I doubt this solves all reported problems. It solves the click in the DocumentationScrollPane, but it does not solve the completion window showing javadoc reported for example by Tomas Musil #20110117 Here is a stack trace: "Code Completion" daemon prio=1 tid=101a36800 nid=0x1728b3000 runnable [1728b0000] java.lang.Thread.State: RUNNABLE at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) - locked <106a1e168> (a java.net.PlainSocketImpl) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.Socket.connect(Socket.java:529) at java.net.Socket.connect(Socket.java:478) at sun.net.NetworkClient.doConnect(NetworkClient.java:163) at sun.net.www.http.HttpClient.openServer(HttpClient.java:394) at sun.net.www.http.HttpClient$4.run(HttpClient.java:457) at java.security.AccessController.doPrivileged(Native Method) at sun.net.www.http.HttpClient.privilegedOpenServer(HttpClient.java:439) - locked <106a1dd90> (a sun.net.www.http.HttpClient) at sun.net.www.http.HttpClient.openServer(HttpClient.java:520) - locked <106a1dd90> (a sun.net.www.http.HttpClient) at sun.net.www.http.HttpClient.<init>(HttpClient.java:233) at sun.net.www.http.HttpClient.New(HttpClient.java:306) at sun.net.www.http.HttpClient.New(HttpClient.java:323) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:975) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:916) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:841) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1177) - locked <1068c16c0> (a sun.net.www.protocol.http.HttpURLConnection) at java.net.URL.openStream(URL.java:1010) at org.netbeans.modules.java.source.JavadocHelper.openStream(JavadocHelper.java:190) at org.netbeans.modules.java.source.JavadocHelper$TextStream.openStream(JavadocHelper.java:156) - locked <1068c1698> (a org.netbeans.modules.java.source.JavadocHelper$TextStream) at org.netbeans.api.java.source.ui.HTMLJavadocParser.getJavadocText(HTMLJavadocParser.java:91) at org.netbeans.api.java.source.ui.HTMLJavadocParser.getJavadocText(HTMLJavadocParser.java:75) at org.netbeans.api.java.source.ui.ElementJavadoc.inheritedDocFor(ElementJavadoc.java:1387) at org.netbeans.api.java.source.ui.ElementJavadoc.prepareContent(ElementJavadoc.java:483) at org.netbeans.api.java.source.ui.ElementJavadoc.<init>(ElementJavadoc.java:303) at org.netbeans.api.java.source.ui.ElementJavadoc.create(ElementJavadoc.java:147) at org.netbeans.modules.editor.java.JavaCompletionDoc.create(JavaCompletionDoc.java:90) at org.netbeans.modules.editor.java.JavaCompletionProvider$JavaCompletionQuery.resolveDocumentation(JavaCompletionProvider.java:561) at org.netbeans.modules.editor.java.JavaCompletionProvider$JavaCompletionQuery.run(JavaCompletionProvider.java:396) at org.netbeans.modules.editor.java.JavaCompletionProvider$JavaCompletionQuery$Task.run(JavaCompletionProvider.java:4903) at org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:154) at org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:138) at org.netbeans.modules.parsing.impl.TaskProcessor$1.call(TaskProcessor.java:201) at org.netbeans.modules.parsing.impl.TaskProcessor$1.call(TaskProcessor.java:198) at org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:167) at org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:323) at org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:66) at org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProcessor.java:198) at org.netbeans.modules.parsing.impl.TaskProcessor.runWhenScanFinished(TaskProcessor.java:235) at org.netbeans.modules.parsing.api.ParserManager.parseWhenScanFinished(ParserManager.java:131) at org.netbeans.modules.editor.java.JavaCompletionProvider$JavaCompletionQuery.query(JavaCompletionProvider.java:288) at org.netbeans.spi.editor.completion.support.AsyncCompletionTask.run(AsyncCompletionTask.java:223)
I can't reproduce any stack trace of that kind; I tried Javadoc completion in a variety of contexts and it was fine. If something is still broken, there should be an assertion error for it, so it will get filed separately.
Created attachment 105562 [details] Sketch of code completion patch - not very nice
No, the assertion is not thrown. The problem is different. The code completion is not called by AWT but it's called under parser lock. The http request is done under the lock => other thread (including AWT) is blocked when ever it touches the parser lock. The assert has to be extend by !JavaSourceAccessor.holdsParserLock()
As this covers several problems, I propose to split this issue. The AWT hang when clicked in the doc - fixed. The Tomas Musil case <cite> #20110117 Big performance problem from my point of view, CC window did not display on my mac at all (i.e. i took > 15s) Finally from selfprofiler i was able to find root cause - reading remote javadoc. IMO this affects all mac user in very significant way, loading of remote javadoc should not block CC. At least there is now a possibility to remove default javadoc (#191914 </cite> I will create a separate issue for it and close this as fixed. OK?
(In reply to comment #18) > I will create a separate issue for it and close this as fixed. Agreed, that should make it easier to track.
I've created a new issue #194969. Marking as fixed.
Integrated into 'main-golden', will be available in build *201102020000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/4fe3904e507a User: Jesse Glick <jglick@netbeans.org> Log: #187919: 6s in java.source.ui.ElementJavadoc.resolveLink() I think fixing all issues not already addressed by #191914. Also introducing an assertion, so that users of dev builds will help track down any remaining problems much more easily and reliably than with the slowness detector.