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.
The significant performance regression was introduced recently before high resistance. It's caused by the fix of issue #213800. The JsfIndex uses wrong base folder in case when there is no WebModule. It tries to use the project folder and asks for the ClassPath.COMPILE on it. This is non sense as the project has *no* classpath and it causes calculation of default synthetic classpath which is wrong for sources inside a project. The project source roots provide classpaths and each of them can provide different classpath. The correct fix of the #213800 should use source root owning the document or null if there is no such a folder. Stack trace: at org.openide.util.lookup.ProxyLookup.lookup(ProxyLookup.java:218) at org.openide.util.lookup.ProxyLookup.lookup(ProxyLookup.java:223) at org.openide.util.lookup.ExcludingLookup.lookup(ExcludingLookup.java:108) at org.openide.util.lookup.ProxyLookup.lookup(ProxyLookup.java:223) at org.openide.util.lookup.SimpleProxyLookup.lookup(SimpleProxyLookup.java:156) at org.netbeans.modules.project.ant.AntBasedProjectFactorySingleton.getHelperFor(AntBasedProjectFactorySingleton.java:455) at org.netbeans.modules.project.ant.ProjectLibraryProvider.getOpenAreas(ProjectLibraryProvider.java:187) at org.netbeans.modules.project.libraries.LibraryAccessor.getOpenAreas(LibraryAccessor.java:100) at org.netbeans.api.project.libraries.LibraryManager.getOpenManagers(LibraryManager.java:550) at org.netbeans.modules.j2ee.deployment.impl.sharability.SourceForBinaryQueryImpl.findSourceRoots2(SourceForBinaryQueryImpl.java:92) at org.netbeans.modules.j2ee.deployment.impl.sharability.SourceForBinaryQueryImpl.findSourceRoots(SourceForBinaryQueryImpl.java:115) at org.netbeans.api.java.queries.SourceForBinaryQuery.findSourceRoots(SourceForBinaryQuery.java:96) at org.netbeans.modules.java.j2seplatform.queries.DefaultClassPathProvider$CompileClassPathImpl.getResources(DefaultClassPathProvider.java:644) at org.netbeans.api.java.classpath.ClassPath.entries(ClassPath.java:350) at org.netbeans.api.java.classpath.ClassPath.getRoots(ClassPath.java:262) at org.netbeans.modules.web.jsf.editor.index.JsfIndex.<init>(JsfIndex.java:82) at org.netbeans.modules.web.jsf.editor.index.JsfIndex.create(JsfIndex.java:67) at org.netbeans.modules.web.jsf.editor.JsfSupportImpl.getIndex(JsfSupportImpl.java:215) at org.netbeans.modules.web.jsf.editor.facelets.FaceletsLibrarySupport.checkLibraryDescriptorsUpToDate(FaceletsLibrarySupport.java:177) at org.netbeans.modules.web.jsf.editor.facelets.FaceletsLibrarySupport.getLibraries(FaceletsLibrarySupport.java:158) at org.netbeans.modules.web.jsf.editor.JsfSupportImpl.getLibrary(JsfSupportImpl.java:200) at org.netbeans.modules.web.jsf.editor.JsfPageMetadataProvider.getMetadataMap(JsfPageMetadataProvider.java:94) at org.netbeans.modules.web.common.api.WebPageMetadata.getMetadata(WebPageMetadata.java:70) at org.netbeans.modules.html.editor.HtmlErrorFilter.getWebPageMimeType(HtmlErrorFilter.java:169) at org.netbeans.modules.html.editor.HtmlErrorFilter.isErrorCheckingEnabledForMimetype(HtmlErrorFilter.java:156) at org.netbeans.modules.html.editor.hints.HtmlHintsProvider.computeErrors(HtmlHintsProvider.java:181) at org.netbeans.modules.html.editor.HtmlErrorFilter.filter(HtmlErrorFilter.java:98) at org.netbeans.modules.csl.core.ErrorFilterQuery.getFilteredErrors(ErrorFilterQuery.java:67) at org.netbeans.modules.csl.core.TLIndexerFactory$TLIndexer.index(TLIndexerFactory.java:248) at org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor$3.run(Indexable.java:216) at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runIndexer(RepositoryUpdater.java:259) at org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor.index(Indexable.java:214) at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$3.run(RepositoryUpdater.java:2803) at org.netbeans.modules.parsing.impl.TaskProcessor.callUserTask(TaskProcessor.java:583) at org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:150) at org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:134) at org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:200) at org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:197) at org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:176) at org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:360) at org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:72) at org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProcessor.java:197) at org.netbeans.modules.parsing.api.ParserManager.parse(ParserManager.java:102) at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.indexEmbedding(RepositoryUpdater.java:2759)
Created attachment 122343 [details] Problematic snapshot
I suggest to roll back the fix of #213800 and create a hot fix patch for NB 7.2 as soon as possible.
Created attachment 122362 [details] Patch for the wrong ClassPath root problem We agreed I'll create a patch for releases/release72 branch and TomasZ will review it. Based on previous agreement with TomasZ I've created a patch for releases/release72 branch which hopefully solves the problem. The change is not tested much, but when Tomas confirms it is ok, I'll do some more testing and possibly provide a build for QE.
the patch is not complete, it fixes the JsfSupportImpl.findForProject() call to the ClassPath.getClassPath(projectRoot), the JsfSupportImpl.getIndex() issue remains... I'll provide one more patch, I'm sorry
Created attachment 122366 [details] Complete patch
Created attachment 122367 [details] Patch #2 with proper type set.
TZ01: ProjectUtil.getSources() never returns null, the check for null can be removed. TZ02: The REJECTED_PROJECTS_CACHE can be probably removed. It caches negative answers only when Sources.getSourceGroups(JAVA).length == 0 It's very fast call when it's cached by Project. It may take some time when it's recalculating but it's used by all IDE features, there is a high probability that it's always cached. The cache is never invalidated and may cause wrong results when a source root is added into a project with no source root. So I suggest simply to remove the cache. Otherwise seems perfect to me.
Created attachment 122395 [details] The final patch Thanks Tomas for the review. I've incorporated the proposed changes and tested the patch a bit. All seems to work fine. Marian, what would be the next step? Should I integrated to the releases/relase72 branch? Or is there an official list of required steps for the 72 patches?
I would integrate the fix into trunk first. After it is tested in trunk, it can be transplanted to release72.
Yes please, integrate into trunk, we will test it and then you can proceed with integration into release72 branch ... see http://wiki.netbeans.org/NetBeansPatchesProcess
I thought there's going to be some relase72_fixes branch so I could use relase72 for testing purposes. The affected code in trunk has already changed not trivially and it will be a different not transplant-able change. I'll make similar changes in trunk and if it is ok, I'll commit the last attached patch to release72.
fixed in web-main#e4d2ba937bd4 QE, please verify so I can proceed with release72 integration.
I was looking at the code and I have a question. What about this code: Collection<FileObject> croots = QuerySupport.findRoots(base, null, null, null); in org.netbeans.modules.web.jsf.editor.index.JsfIndex.<init>? I guess this will cause similar problem, since it again uses 'base' variable, which contains project directory.
(In reply to comment #13) > I guess this will cause similar problem, since it again uses 'base' variable, > which contains project directory. Sure, it does. QuerySupport.findRoots() invokes ClassPath.getClassPath(base,..) and we have the same problem as before.
(In reply to comment #12) > QE, please verify so I can proceed with release72 integration. I'll do it after the issue will be fixed again, thanks
(In reply to comment #14) > (In reply to comment #13) > > I guess this will cause similar problem, since it again uses 'base' variable, You are right Tome. Thanks for catching this.
The "QuerySupport.findRoots(base, null, null, null)" problem hopefully fixed in http://hg.netbeans.org/web-main/rev/5ac1b33d8202 I tried to preserve the original behavior of the QuerySupport.findRoots(...) in a custom code since I haven't found an alternative using the QS. Maybe Tomas Zezula could help in finding an alternative way of fixing? At least please do review the fix once more Tomasove. Thanks in advance!
Integrated into 'main-golden', will be available in build *201207270002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/e4d2ba937bd4 User: Marek Fukala <mfukala@netbeans.org> Log: #215930 - Performance regression in scanning caused by JSFIndex
verified in trunk, I didn't find any problems. If that's ok, I'll wait for the review and then change status to verified. Product Version: NetBeans IDE Dev (Build 201207270002) Java: 1.7.0_06-ea; Java HotSpot(TM) Client VM 23.2-b09 System: Linux version 3.0.0-21-generic-pae running on i386; UTF-8; en_US (nb)
(In reply to comment #19) > verified in trunk, I didn't find any problems. If that's ok, I'll wait for the > review and then change status to verified. > > > Product Version: NetBeans IDE Dev (Build 201207270002) > Java: 1.7.0_06-ea; Java HotSpot(TM) Client VM 23.2-b09 > System: Linux version 3.0.0-21-generic-pae running on i386; UTF-8; en_US (nb) The tested build 201207270002 does not contain the second fix. This build is still broken.
You're right, sorry. I didn't noticed older changeset in message from QualityEng. Thanks
(In reply to comment #17) > The "QuerySupport.findRoots(base, null, null, null)" problem hopefully fixed in > > http://hg.netbeans.org/web-main/rev/5ac1b33d8202 > > I tried to preserve the original behavior of the QuerySupport.findRoots(...) in > a custom code since I haven't found an alternative using the QS. I noticed that private QuerySupport createEmbeddingIndex() and private QuerySupport createCustomIndex() has identical body. Is it intentional?
(In reply to comment #22) > I noticed that > private QuerySupport createEmbeddingIndex() > and > private QuerySupport createCustomIndex() > has identical body. Is it intentional? Sorry, they are not identical - the use same classpath, while in previous version they used different.
(In reply to comment #17) > The "QuerySupport.findRoots(base, null, null, null)" problem hopefully fixed in > > http://hg.netbeans.org/web-main/rev/5ac1b33d8202 > > I tried to preserve the original behavior of the QuerySupport.findRoots(...) in > a custom code since I haven't found an alternative using the QS. > > Maybe Tomas Zezula could help in finding an alternative way of fixing? > > At least please do review the fix once more Tomasove. The fix looks OK - it fixes the performance regression.
verified in trunk Product Version: NetBeans IDE Dev (Build 201208130001) Java: 1.7.0_06; Java HotSpot(TM) Client VM 23.2-b09 System: Linux version 3.0.0-23-generic-pae running on i386; UTF-8; en_US (nb)
changeset: 237137:d812f70ace7e summary: #215930 - manual backport from trunk - Performance regression in scanning caused by JSFIndex changeset: 237142:3b5a662b01f3 summary: #215930 - increasing spec version and adding long description
Integrated into 'releases', will be available in build *201209010822* or newer. Wait for official and publicly available build. Changeset: http://hg.netbeans.org/releases/rev/d812f70ace7e User: Marek Fukala <mfukala@netbeans.org> Log: #215930 - manual backport from trunk - Performance regression in scanning caused by JSFIndex
JSF Editor works as expected in patch => patch1 verified Product Version: NetBeans IDE 7.2 (Build 201207171143) Java: 1.7.0_07; Java HotSpot(TM) Client VM 23.3-b01 System: Linux version 3.2.0-29-generic-pae running on i386; UTF-8; en_US (nb)