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.
Build: NetBeans IDE Dev (Build 201002170200) VM: Java HotSpot(TM) 64-Bit Server VM, 14.3-b01-101, Java(TM) SE Runtime Environment, 1.6.0_17-b04-248-10M3025 OS: Mac OS X Maximum slowness yet reported was 16035 ms, average is 16035
Created attachment 94309 [details] nps snapshot
This issue is a mess. There is 86 duplicates but several different problems are mixed here. I evaluated last 10 snapshots and identified four of them. Denis, two of them are related to your changes long time ago. They (your changes) look OK to me and they should have fixed the problem. Passing to you for now. At least for your opinion. Thanks in advance. I think we should evaluate these four cases and then we can close this issue. #1) reports related to WebReplaceTokenProvider.isServletFile (fixed as issue 172931) http://statistics.netbeans.org/exceptions/exception.do?id=467136 http://statistics.netbeans.org/exceptions/exception.do?id=463111 http://statistics.netbeans.org/exceptions/exception.do?id=457365 http://statistics.netbeans.org/exceptions/exception.do?id=457086 #2) reports related to ConfFilesNodeFactory.ConfFilesChildrenFactory (fixed as issue 170098)(I'm not sure this is our problem - AsynchChildren.getNodes is called from AWT which does not make sense to me) http://statistics.netbeans.org/exceptions/exception.do?id=465962 http://statistics.netbeans.org/exceptions/exception.do?id=463620 #3) related to JSFBeanCache.getBeans (this is a new one; Denis could you have a look please?) http://statistics.netbeans.org/exceptions/exception.do?id=465428 http://statistics.netbeans.org/exceptions/exception.do?id=465651 http://statistics.netbeans.org/exceptions/exception.do?id=463528 #4) this one is obsolete so it can be ignored - source code was rewritten since then: http://statistics.netbeans.org/exceptions/exception.do?id=467369
First item ( 1) ) This is from first mentioned profiler snapshot : org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(): 18002 / 0 java.util.concurrent.locks.ReentrantLock.lock(): 17910 / 0 .... org.netbeans.modules.j2ee.metadata.model.api.support.annotation. AnnotationModelHelper$2.run(): 91 One can see from here that most time of the "convert" method ( which is direct consequence of UI action ) belongs to java.util.concurrent.locks.ReentrantLock.lock() ( more than 17 seconds !) and only 91ms belongs to J2EE functionality method invocation. The ReentrantLock.lock() has no relation to JEE functionality. This could be a problem of used JDK version ( it seems 1.6.0_22 and 1.6.0_23 are affected ) or bad usage this JDK library class inside parsing TaskProcessor . So the resolution is : this is not javaee functionality bug. May be this is issue of Java version. Try it with different version. I'm investigating other items.
The second item ( 2) ) . You are rite about calling AsynchChildren.getNodes from AWT thread. I suppose this is not regular case ( when nodes appears under Project nodes on drawing ) but the case when user invokes some special action f.e. from editor popup menu action "Select in Projects" . Probably this case is handled via specific logic and in the latter case call is done via AWT thread. But anyway this is not the client code problem. This is the problem of the implementation UI action or bad design usage of AsynchChildren. This is not a JEE functionality bug definitely .
I'm sorry about first item. I was incorrect. I have looked only at AWT thread where problem is reported . But the problem is not in AWT thread actually. My notions are still correct : AWT is blocked by TaskProcessor.runUserTask() which waits for free of the lock. So the time spent on the lock is not a JDK problem or parsing API TaskProcessor. This is the consequence of acquiring lock in the different thread. The latter thread is created as additional "feature" for avoiding performance problem but as result it introduce the problem itself. I'm going to fix it.
Third item ( 3) ) : the problem is also not in AWT thread itself but some different threads which blocks parsing lock acquisition. In one case this is Code Completion thread which call org.netbeans.modules.parsing.impl.indexing.Util.resolveUrl() takes more than 22 seconds under parssing TaskProcessor block. In the other case this is JSP parsing thread which call org.apache.jasper.compiler.Node$Visitor.visitBody() takes more than 40 seconds under under parssing TaskProcessor block. And so on. The the real JSF model logic doesn't take many time itself. The AWT block is consequence of waiting parsing lock acquisition. As result call of JSF model could be time consuming procedure. And it should be taken into account by clients of the model. In the considered cases ( it seems ) Go To action is such a client : org.netbeans.lib.editor.hyperlink.HyperlinkOperation.performHyperlinking() delegates as result to org.netbeans.modules.web.jsf.editor.el.JsfHyperlinkProvider.getHyperlinkSpan() This client should care about time consuming task of JSF model invocation. My proposition is to do something similar as I have done for Servler run action: shows the dialog "Scanning in progress...". Run the model access action in the separate thread. When model access action is finished : close dialog window and perform navigation action. An option : start the model access action in the separate thread and check result after some reasonable time. In case of result absence : show dialog and wait of result with dialog showing. If result is already discovered ( after mentioned reasonable time f.e. 500ms ) then perform navigation immediately without dialog showing. In any case : this is should be done on the client side in the JsfHyperlinkProvider.
This is the fix for first item problem : changeset: 186557:48b3870b593a
Reassigning to JSF functionality for third item fix.
org.netbeans.modules.web.jsf.editor.el.JsfHyperlinkProvider.getHyperlinkSpan() does not call the parsing infrastructure anymore
Cool! Thanks guys for resolving these. What remains is: #2) reports related to ConfFilesNodeFactory.ConfFilesChildrenFactory (fixed as issue 170098)(I'm not sure this is our problem - AsynchChildren.getNodes is called from AWT which does not make sense to me) http://statistics.netbeans.org/exceptions/exception.do?id=465962 http://statistics.netbeans.org/exceptions/exception.do?id=463620 which I'm passing to platform for evaluation. Once that's done this issue can be closed.
Both reports: http://statistics.netbeans.org/exceptions/exception.do?id=465962 http://statistics.netbeans.org/exceptions/exception.do?id=463620 seem to be stuck in org.netbeans.modules.project.ui.ProjectTab$KeepExpansion.run(). Very likely this computation needs to be done outside of AWT.
Integrated into 'main-golden', will be available in build *201101190000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/48b3870b593a User: Denis Anisimov <ads@netbeans.org> Log: Fix for BZ#180934 - 16s web.project.ui.WebLogicalViewProvider.findNodeInConfigFiles()
Please reconsider this issue. When sending Error Report I allways end up here. With out this issue beeing solved Netbeans 7.0 is not useable for me when working on maven projects that use JSF.
Still happens with NB 7.0.1. Can I provide any more information to help getting this issue fixed?
(In reply to comment #10) > AsynchChildren.getNodes is called from AWT which does not make sense to me ChildFactory.createNodesForKey may be called synchronously and is expected to be fast. Any "real work" you need to do should be in createKeys.
(In reply to comment #13) > When sending Error Report I [always] end up here. lallafa's problem is apparently unrelated to the title of this bug and just thrown in here by accident since the slowness reporter is rather crude. The issue there is maven.j2ee.web.WebReplaceTokenProvider conditionally enabling some action based on whether or not the selected file is a servlet, which is an expensive check (needs to wait for classpath scanning to complete). Bug #177262 would prevent a GUI freeze from resulting, but responsiveness would still be poor. Probably better to unconditionally enable the action on Java sources and just show a warning when invoked if it turns out to not actually be a servlet; or perhaps initially return true for enablement and asynchronously disable it later if necessary, caching the servlet check for later; etc. lallafa please file this separately (with whatever steps to reproduce you may know of) in javaee/maven and refer to your http://statistics.netbeans.org/exceptions/exception.do?id=523510 and http://statistics.netbeans.org/exceptions/exception.do?id=518055 as examples.
(In reply to comment #16) > [...] maven.j2ee.web.WebReplaceTokenProvider conditionally enabling > some action based on whether or not the selected file is a servlet, which is an > expensive check Please file an issue - servlet check is expensive and should be done in background and result should be stored as a FileObject property. Action should immediately return false and later it may get enabled. That's how it works for Ant Web Project.
(In reply to comment #17) > Please file an issue OK, I filed bug #200997.
latest report is from 7.1 RC1 and there are not even any new comments - doesn't seem to be a problem any more