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.
Although we have experienced not s single functional regression with our specialized Jato Jsp DataObject while porting S1AF module from Studio 4.1 to Studio 5.0, unfortunately, the CPU resource utilization caused (we think) by the TagLib parsing is causing problems. We clearly see differences in expected response time even when dealing with a single JSP. Our New Page (ViewBean) Wizard produces a pause even on a fast machine due to the creation of a new JSP. Sometimes the pause is severe and when we catch a stack trace we see that the Jasper integration is running as part of TagLibParser code paths. We suspect that sometimes there is a priority inversion on the thread which makes things worse but we are no sure on that point. While running through some Jsp test cases recently we focused on this issue again. In order to open this issue we wanted to have a reproducable experience which did not require S1AF. We are fairly confident that this is a S1S5 generic issue. Our module does not use any of the JSP debuging or TagLib code paths. Our only requirement on the JspIEDataObject which we specialize is to be able to call getSwingDocument() and generate our own Token stream from the JspSyntaxAnalyzer so that we can do our own programmatic Jsp editing. The CPU impact is acute when using our module because we kick off a task to generate a JSP DOM and in doing this we call getSwingDocument(). In the non-S1AF case getSwingDocument() is usally not called until the JSP file is opened. Therefore, we have the following test case. Without S1AF module installed, I mount a web app which has a folder with 33 JSPs (none of them very large or complex only 2-4k) See attached web app called JspTesting and the document folder /tests/testjsps/sample When I open this folder the 33 JSP nodes display promptly. If I select all the files and choose Open (in order to open all the files in the editor and invoke the getSwingDocument())...the result is on a 600Mhx PIII it takes 2-3 minutes for the IDE calm down from all the CPU processing of the TagLibParsing. The CPU is pegged all this time and the IDE UI is hosed partially. The stack trace is attached. Looks like some heavy lifting BeanIntrospector work which is not cached from JSP to JSP. I really do not know what is proper for Priority here. Please adjust if necessary. The impact to S1S5 on its on speaks for itself. It is very common for the enterprise to have hundreds of JSP. No although it is not common for someone to open a bunch at the same time if they close and reopen the IDE they will solicit a multiple open indirectly when the IDE reopens all the previously opened JSPs. It appears that the Jasper processing is done in serial because on a dual processor machine we only every see one thread running and one CPU pegged.
Created attachment 11627 [details] Stack trace taken while IDE was CPU bound and unresponsive while opening JSPs
Created attachment 11628 [details] Sample Web App with example JSPs
We have always experienced a lot of invalid filesystema loader activity during unmounts of web apps. In the test case I described where the 33 files are opened in the IDE. Try this too. Unmount the web app with the JSPs open in the editor. On my 600Mhz Piii it took over a minute for the unmount to complete..stack traces reveal the same code path realized during open. Again, this can be seen without the S1AF module loaded. at org.apache.jasper.compiler.ParserController.parse (ParserController.java:214) at org.netbeans.modules.web.jspparser.JspParserImpl.callTomcatParser (JspParserImpl.java:126) at org.netbeans.modules.web.jspparser.JspParserImpl.parsePage (JspParserImpl.java:117) at org.netbeans.modules.web.core.jsploader.TagLibParseSupport$ParsingRunn able.run(TagLibParseSupport.java:119)
My own experience with this problem is that the JSP parsing task frequently runs at thread priority 9, which brings my entire IDE to a standstill until it completes. Furthermore, I can see in the stack traces I've done that the parser task is reloading classes from scratch every single time it runs (including reloading from JAR and ZIP files).
Todd, I can confirm your observation regarding reloading classes each time. This issue was identified and fixed in the current code base (NetBeans 4.0 / S1S Sequoia).
Thanks for the speedy response. This is good and bad news. What can we do about it for Stripes? Is a patch possible? Otherwise, is there any sort of workaround we can employ in our module? This is a pretty signficant problem for us since our module does a huge amount of JSP editing.
The approach we took in fixing this was that we keep a reference to the classloader which loads classes from the user's application, instead of creating it every time. Then we listen on the changes in the user's classes and dispose of the classloader when the application changes. Regarding the fix, we still haven't answered some process questions: - Will there need to be a revision of the WebApps support modules, or will the S1S 5 version be sufficient? - If we provide a new version, who will be responsible for delivering it? The development group, or the sustaining group? - What will be the code base (branch) for these changes? - Are there any other modules that you will need patched? If so, then we should agree on the same approach. I must say I can't think of a way how this particular issue could be addressed in your module.
Petr-- Very interesting, as we have a similar requirement in our application. We dynamically load component libraries using the equivalent of TopManager.currentClassLoader() and are seeing some problems with multiple classes being loaded (that's an entirely different topic). But, it might be useful to see the nature of the change you made for this bug. Can you provide a pointer to source files and versions? As for the process question, we need to bring Charles Beckham and Trung into the conversation.
This should be reassigned and target milestone set I guess.
Todd and Matthew, is there anything I can do at this point to help out with this bug? My recommendation would be that you use the new JSP editor and JSP parser module, that is currently in the trunk. I wrote to Tor some time ago how to integrate them into Rave. That would give you the new code that has the fix.
Petr, if I understand correctly...you are saying that latest version of the JspDataObject and related code has this fixed? Or is there new/additional code? I will check with Todd, but I think that for S1AF module we are relying on codebase at hand. We noticed this problem in the Stripes (Nevada 3.5) codebase. Has this issue been fixed in the Arrow (Nevada trunk)? matt
Yes, I believe the performance has improved, but I haven't done any specific measurements. The new code is in open source trunk (not in Arrow or Stripes).
Per previous discussion, changing to FIXED. Please reopen if this is still a problem in the NetBeans 3.6 codebase.
v