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.
Bug exists in FFJ EE EA RC-1 build (v.4.0-EA (Build 020301_1)) with JDK1.4. After compilation of some number of JSPs switching between Tomcat server becomes very slow and loads 100% of CPU. Thus on P4 1.8 GHz machine it takes approximately 30 seconds to switch between two server instances !!! How to reproduce: 1. Unjar jsp-tests.war file from <Jakarta WatchDog to dir>/webapps file 2. Mount this web module 3. Call Compile All on the jsp directory 4. Try to switch between two target Tomcat server instances for this web module when finished and notice that now this operation takes a lot of time and loads 100% of CPU.
looks like related with JSP compilation I will measure these problem with the optimizeIt
and where is the attachment?
I was not able to find cuirrent war file. Can you attach this file in this bug? I tried this with 20 simple JSPs and it worked for me. win 2000; jdk 1.4; ee forte 2000304 - create 20 simple JSPs - add external tomcat installation - build all - change target server - no performance problem please add your war file and repopen this bug
Created attachment 4947 [details] WAR file with test web module
new attachment
very strange: it throws the exception win 2000; jdk 1.4; forte ee Build 20020306-1005 - unjar the war file - mount the FS from the war file - set target server as internal tomcat - select JSP folder - compile all or build all can you Petr look at this? exception: Wed Mar 06 14:02:10 CET 2002: java.lang.NumberFormatException: a java.lang.NumberFormatException: a at java.lang.Integer.parseInt(Integer.java:426) at java.lang.Integer.parseInt(Integer.java:476) at tags.SillyArgsExtraInfo.isValid(SillyArgsExtraInfo.java:89) at javax.servlet.jsp.tagext.TagInfo.isValid(TagInfo.java:234) at org.apache.jasper.compiler.TagBeginGenerator.validate (TagBeginGenerator.java:189) at org.apache.jasper.compiler.TagBeginGenerator.init (TagBeginGenerator.java:129) at org.netbeans.modules.web.jspparser.AnalyzerParseEventListener.addGener ator(AnalyzerParseEventListener.java:157) at org.netbeans.modules.web.jspparser.AnalyzerParseEventListener.handleTa gBegin(AnalyzerParseEventListener.java:947) at org.apache.jasper.compiler.DelegatingListener.handleTagBegin (DelegatingListener.java:217) at org.apache.jasper.compiler.DelegatingListener.handleTagBegin (DelegatingListener.java:212) at org.apache.jasper.compiler.Parser$Tag.accept (Parser.java:840) at org.apache.jasper.compiler.Parser.parse(Parser.java:1133) at org.apache.jasper.compiler.Parser.parse(Parser.java:1091) at org.apache.jasper.compiler.Parser.parse(Parser.java:1087) at org.apache.jasper.compiler.ParserController.parse (ParserController.java:213) at org.netbeans.modules.web.jspparser.JspParserImpl.callTomcatParser (JspParserImpl.java:127) at org.netbeans.modules.web.jspparser.JspParserImpl.analyzePage (JspParserImpl.java:94) at org.netbeans.modules.web.core.jsploader.JspDataObject.createCompiler (JspDataObject.java:313) at org.netbeans.modules.web.core.jsploader.JspCompilerSupport.addToJob (JspCompilerSupport.java:67) at org.openide.loaders.CompilerSupport.prepareJobFor (CompilerSupport.java:174) at org.openide.loaders.DataFolder$Cmp.addToJob (DataFolder.java:1347) at org.openide.loaders.CompilerSupport.prepareJobFor (CompilerSupport.java:174) at org.openide.loaders.CompilerSupport.prepareJob (CompilerSupport.java:141) at org.openide.actions.AbstractCompileAction.compileNodes (AbstractCompileAction.java:106) at org.openide.actions.AbstractCompileAction.performAction (AbstractCompileAction.java:47) at org.openide.util.actions.NodeAction.performAction (NodeAction.java:180) at org.openide.util.actions.NodeAction.actionPerformed (NodeAction.java:171) at org.netbeans.core.ModuleActions$1.run (ModuleActions.java:105) at org.openide.util.Task.run(Task.java:152) [catch] at org.openide.util.RequestProcessor$ProcessorThread.run (RequestProcessor.java:622)
The exceptions reported by Damian are because of (intentional) errors in the test application, and because of bad handling of errors by Tomcat. Still, the problem reported by Mikhail is reproducible once you get past these exceptions. The cause of the problem is that the changes in the references to the generated servlets in JSP objects are done in the foreground (AWT thread), which blocks the IDE. The fix is to compute these changes in the background (RequestProcessor) thread. The fix has been committed.
Changing target milestone to FFJ 4.0
Resolved for 3.4.x or earlier, no new info since then -> verify.
Resolved for 3.4.x or earlier, no new info since then -> closing.