Community
Participate
Working Groups
Build Identifier: 3.2.1 I am experiencing the reproducible problem that the java indexing thread causes high cpu load for several minutes after a build took place. All Web/WTP validators are configured as suspended in the preference dialog. Please have a look at the following thread dump which has been taken after a build finished and while the cpu usage can be seen: (although I cannot see any active background tasks in the progress monitor) org.eclipse.jst.jsp.core.internal.parser.internal.JSPTokenizer.primGetNextToken() (line: 2120) org.eclipse.jst.jsp.core.internal.parser.internal.JSPTokenizer.getNextToken() (line: 1643) org.eclipse.wst.xml.core.internal.parser.XMLSourceParser.getNextRegion() (line: 189) org.eclipse.jst.jsp.core.internal.parser.JSPSourceParser.parseNodes() (line: 237) org.eclipse.wst.xml.core.internal.parser.XMLSourceParser.getDocumentRegions() (line: 173) org.eclipse.wst.sse.core.internal.text.StructuredDocumentReParser._core_reparse_text(int, int) org.eclipse.wst.sse.core.internal.text.StructuredDocumentReParser.core_reparse(int, int, org.eclipse.wst.sse.core.internal.text.CoreNodeList, boolean) (line: 710) org.eclipse.jst.jsp.core.internal.parser.JSPReParser.reparse(org.eclipse.wst.sse.core.internal.provisional.text.IStructuredDocumentRegion, org.eclipse.wst.sse.core.internal.provisional.text.IStructuredDocumentRegion) (line: 143) org.eclipse.wst.sse.core.internal.text.StructuredDocumentReParser.reparse() (line: 1291) org.eclipse.wst.sse.core.internal.text.BasicStructuredDocument.updateModel(java.lang.Object, int, int, java.lang.String) (line: 2709) org.eclipse.wst.sse.core.internal.text.BasicStructuredDocument.internalReplaceText(java.lang.Object, int, int, java.lang.String, long, boolean) (line: 1923) org.eclipse.wst.sse.core.internal.text.BasicStructuredDocument.replaceText(java.lang.Object, int, int, java.lang.String, long, boolean) (line: 2419) org.eclipse.wst.sse.core.internal.text.BasicStructuredDocument.setText(java.lang.Object, java.lang.String) (line: 2606) org.eclipse.wst.sse.core.internal.text.JobSafeStructuredDocument.setText(java.lang.Object, java.lang.String) (line: 188) org.eclipse.wst.sse.core.internal.text.BasicStructuredDocument.set(java.lang.String) (line: 2481) org.eclipse.jst.jsp.core.internal.java.XMLJSPRegionHelper.parse(java.lang.String) (line: 159) org.eclipse.jst.jsp.core.internal.java.JSPTranslator.handleIncludeFile(java.lang.String) (line: 2310) org.eclipse.jst.jsp.core.internal.java.JSPTranslator.translateDirective(java.util.Iterator) (line: 2033) org.eclipse.jst.jsp.core.internal.java.JSPTranslator.translateJSPNode(org.eclipse.wst.sse.core.internal.provisional.text.ITextRegion, java.util.Iterator, java.lang.String, int) (line: 1766) org.eclipse.jst.jsp.core.internal.java.JSPTranslator.translateRegionContainer(org.eclipse.wst.sse.core.internal.provisional.text.ITextRegionCollection, int) (line: 1349) org.eclipse.jst.jsp.core.internal.java.JSPTranslator.translate() (line: 1127) org.eclipse.jst.jsp.core.internal.java.JSPTranslationAdapter.getJSPTranslation() (line: 153) org.eclipse.jst.jsp.core.internal.java.search.JSPSearchDocument.getJSPTranslation() (line: 120) org.eclipse.jst.jsp.core.internal.java.search.JSPSearchDocument.getCharContents() (line: 77) org.eclipse.jst.jsp.core.internal.java.search.JavaSearchDocumentDelegate.getCharContents() org.eclipse.jdt.internal.core.search.indexing.SourceIndexer.indexDocument() (line: 60) org.eclipse.jdt.internal.core.search.JavaSearchParticipant.indexDocument(org.eclipse.jdt.core.search.SearchDocument, org.eclipse.core.runtime.IPath) (line: 72) org.eclipse.jst.jsp.core.internal.java.search.JSPSearchParticipant.indexDocument(org.eclipse.jdt.core.search.SearchDocument, org.eclipse.core.runtime.IPath) (line: 72) org.eclipse.jdt.internal.core.search.indexing.IndexManager.indexDocument(org.eclipse.jdt.core.search.SearchDocument, org.eclipse.jdt.core.search.SearchParticipant, org.eclipse.jdt.internal.core.index.Index, org.eclipse.core.runtime.IPath) (line: 453) org.eclipse.jdt.internal.core.search.indexing.IndexManager$1.execute(org.eclipse.core.runtime.IProgressMonitor) (line: 853) org.eclipse.jdt.internal.core.search.processing.JobManager.run() (line: 404) java.lang.Thread.run() (line: 662) I debugged it and tracked it down: The reason for this is that JSPSearchSupport and JSSearchSupport class consider every type of resources. However, they should only consider special resource types (e.g. non-derived, only specific extensions etc.). In my development environment we have have many derived resources which impacts the build time in combination with this bug. Reproducible: Always Steps to Reproduce: 1. Create a dynamic web project 2. Copy many (let's say >500) files/JSPs in your web content folder 3. Mark them as derived 4. Build your project 5. You have to wait several minutes before cpu load will drop down to idle
Created attachment 191682 [details] patch
Thanks for opening the defect. However, this doesn't quite fit the definition of "critical" which is used to indicate crashes, data loss and severe memory leaks.
Wouldn't IPath.isRoot() be better than path.toString().equals("/")?
(In reply to comment #3) > Wouldn't IPath.isRoot() be better than path.toString().equals("/")? Thats from my original code. And its probably there because I did not know of "isRoot". I wouldnt see any problem with changing it to isRoot assuming it does the same thing.
Code released.
Nick, I tested your patch - it seems that JSIndexManager is still processing derived resources. (JSPIndexManager is now fine)
(In reply to comment #6) > Nick, > > I tested your patch - > it seems that JSIndexManager is still processing derived resources. > (JSPIndexManager is now fine) Patric, Right now, the JSIndexManager is still not based on the AbstractIndexManager, which we were able to apply this fix to. A separate bug would need to be opened against the JSDT as their index implementation is different.
Done: bug 340774
