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.
NB-big Dev (200704180000), JDK 1.5.0_12 Steps to reproduce: - open HugeApp project (attachment) - expand Web Pages - select Page1.jsp - invoke popup menu - push Open -> the IDE got frozen for 2 minutes (Pentium M 2GHz, 1GB RAM, Ubuntu) 1. looks like all the stuff is running in AWT (see attached log) .. a lot off : WARNING [org.netbeans.api.java.source.JavaSource]: JavaSource.runUserActionTask called in AWT event thread by: java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149) 2. if this action has to take long time, change the cursor to clocks as we do for all other time consuming actions
Created attachment 41175 [details] Huge Application
Created attachment 41176 [details] thread-dumps
This is the problem of constructing the model + scanning etc. It is not a designer issue, the component opening is blocked by those events (as one can see from the thread dumps). Passing to insync.
This is an issue of perceived performance. This happens because since Creator days Insync does the work on AWT thread. That work should be done on a separate thread to make UI responsive.
This is an architectural issue with Insync and the client code. Since Creator days Insync has handled the client requests synchronously. To fix the issue it will require analysis and changes to the Insync architecture and how the client code will access the Insync services. This will not be possible in the time available for M9. Asking for Waver for M9.
I think we could live with this few more months (hope fixed soon after M9).
Providing part of the fix to try out (this part is about avoiding loading from AWT thread): Start IDE with -J-Dvwp.designer.jsf.loadModelAsync=true to force designer comp to load the FacesModel asynchronously. It will provide message "Loading, wait please..." until the model is constructed. This is just to try it out, the final fix on this perceived perf would need some support from insync. Last change of that part (there were a lot of previous related changes): Checking in visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/JsfForm.java; /cvs/visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/JsfForm.java,v <-- JsfForm.java new revision: 1.71; previous revision: 1.70 done Checking in visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/ui/Bundle.properties; /cvs/visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/ui/Bundle.properties,v <-- Bundle.properties new revision: 1.3; previous revision: 1.2 done Checking in visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/ui/JsfTopComponent.java; /cvs/visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/ui/JsfTopComponent.java,v <-- JsfTopComponent.java new revision: 1.32; previous revision: 1.31 done
I ran the following two scenarios. Setup: Start with clean user dir. Start IDE Add Glassfish server using the Tools:Servers. Scenario 1: 1. Create NetBeans Web Java EE 5 project with JSF Framework. 2. Add the JDBC Runtime library, Web UI component library, JSF 1.2 Support library to this project. I added these libraries to make as close as possible to the VW framework project. 3. Create a Java class. 4. Use Go To Type dialog to find AbstractPageBean class. 5. With the Java file still showing close the IDE. 6. Cleanup the <userdir>/var/cache. 7. Start the IDE 8. As soon as the Java editor is open, invoke the Go To Type dialog (using Alt+Shift+O) and type AbstractPageBean. At this point measure with the stop watch the time it takes for the Go To Type dialog to find the class. It took ~ 1 min 22 seconds 9. Close the project 10. Close the IDE --- Cleanup the <userdir>/var/cache. --- Scenario 2: 1. Run the IDE. 2. Create a NetBeans Web Java EE 5 project with VW framework. 3. From the time I hit the Finish button of the New Project wizard till it disappears ~ 13 secs elapse. 4. The Classpath scanning progress bar starts in the status bar. 5. Count seconds till the Designer shows the page. This takes ~ 1 min 38 secs We tried the same scenarios on my : Sony Vaio (Laptop) T2500 @ 2.00GHz 1.99GHz, 2.00 GB of RAM and Winstons: Apple MacOS Notebook (Intel) Basically we got the same numbers. I ran the scenario thrice on machine. Basically the same numbers. So as you can see the W enabled web project adds about 14 secs over the scenario with NetBeans Web project with JSF. I chose the Go To Type dialog scenario for NetBeans Web Java EE 5 project with JSF Framework with the assumption that this requires more or less equivalent services or at leat finishing of the initial (clean cache) Class path scan to finish. Of course to support the design time VW designer+insync has to do additional work of starting built in JSF container and some other stuff. So the additional 14 seconds makes somewhat sense. Even if we brought down that overhead it is still going to take about 1 min and 22 sec on my very fast machine. I grant that this is an approximate comparison. However it shows the problem area in the borad sense. We need to speed up the initial (clean cache) scanning of the classpath of a project.
Adding to the J1_STOPPER list on behalf of QA who earlier today stated that this was a preview showstopper.
Sandip, I think the information about how long it takes to scan the files is useful and it should be improved if possible, but you missed an important point. It does not take 1 1/2 minutes to open a Java file in editor. It may take that time to get all the features displayed, like folds, semantic coloring, etc., but the file is open first and additional stuff is added later when available. I think this is a very important difference. Maybe something like that could be done for visual pages in future.
The issue is that for VW page, access to the Designer is the primary function. For Designer to come up the modeling needs to happen, which in trun requires access to Retouche. In case of Java editor, simple code editing does not require Retouche services. The services such as hints, error highlighting can start appearing after a delay. But think of it this way: what happens if the user invokes Go To type dialog? Does it come up and become fully functional right away. No. VW is in a similar situation. Having said that we are in fact trying to implement what you suggest in some ways i.e. we will do the modeling on a different thread. In the mean time the Designer will show some message like "Loading. Please wait...". This still means that the user will not be able to access the primary function of Visual Design. The user will be able to work with other parts of the IDE. There is a risk involved in this as now the user will be able to access functionality that they could not before - some of which may have indirect dependency on full modeling.
Sandip, thanks, I think that's the right direction.
*** Issue 97649 has been marked as a duplicate of this issue. ***
Bug Fix# 101604 IDE is frozen for loooong time during opening JSP page The factors that cause the issue are: 1. Insync needs to model the sources to support the Designer. Insync uses Retouche to model the sources. Internally Retouche builds the indices for all the jars in the project's classpath. In case of VW Web project there are many entries on the classpath: - JDK stuff - App Server Stuff - Component libraries - DataProvider and Appbase libraries The scanning and building of class indices takes some time. Before the fix for issue: http://www.netbeans.org/issues/show_bug.cgi?id=99923 this was even worse as Insync was blocked until the full scan finished. With the fix for issue 99923, Retouche tries to serve the Insync requests between Jar file scanning. So this has helped the VW project creation performance somewhat. 2. The other issue was that Insync calls the Retouche services on the AWT thread, which basically makes the GUI completely non-responsive (no scanning animation, gray window when the IDE is obscured and the exposed again etc.) This fix primarily addresses the number 2 by moving the call to Retouche services during initial modeling in Insync to a background thread. This allows the Designer to show the "Loading. Please wait...." label while the initial modeling is going on, the scanning animation works and the UI remains responsive. The user can click around in the IDE, The Designer refreshes once the modeling is complete. This behavior can be reverted to the original behavior by setting the system property vwp.designer.jsf.loadModelSync to true. Checking in actions/RefreshProjectDataSourceAction.java; /cvs/visualweb/dataconnectivity/src/org/netbeans/modules/visualweb/dataconnecti vity/actions/RefreshProjectDataSourceAction.java,v <-- RefreshProjectDataSourceAction.java new revision: 1.1.20.1; previous revision: 1.1 done Checking in actions/ResolveProjectDataSourceAction.java; /cvs/visualweb/dataconnectivity/src/org/netbeans/modules/visualweb/dataconnecti vity/actions/ResolveProjectDataSourceAction.java,v <-- ResolveProjectDataSourceAction.java new revision: 1.2.2.1; previous revision: 1.2 done Checking in explorer/ProjectDataSourceNodeChildren.java; /cvs/visualweb/dataconnectivity/src/org/netbeans/modules/visualweb/dataconnecti vity/explorer/ProjectDataSourceNodeChildren.java,v <-- ProjectDataSourceNodeChildren.java new revision: 1.2.6.1; previous revision: 1.2 done Checking in ProjectDataSourceTracker.java; /cvs/visualweb/dataconnectivity/src/org/netbeans/modules/visualweb/dataconnecti vity/project/datasource/ProjectDataSourceTracker.java,v <-- ProjectDataSourceTracker.java new revision: 1.2.10.1; previous revision: 1.2 done Checking in DomProviderImpl.java; /cvs/visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/Dom ProviderImpl.java,v <-- DomProviderImpl.java new revision: 1.14.2.1; previous revision: 1.14 done Checking in JsfForm.java; /cvs/visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/Jsf Form.java,v <-- JsfForm.java new revision: 1.71.2.1; previous revision: 1.71 done Checking in ui/AbstractJsfTopComponent.java; /cvs/visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/ui/ AbstractJsfTopComponent.java,v <-- AbstractJsfTopComponent.java new revision: 1.5.2.1; previous revision: 1.5 done Checking in ui/JsfTopComponent.java; /cvs/visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/ui/ JsfTopComponent.java,v <-- JsfTopComponent.java new revision: 1.32.2.1; previous revision: 1.32 done Checking in Designer.java; /cvs/visualweb/designer/src/org/netbeans/modules/visualweb/api/designer/Designe r.java,v <-- Designer.java new revision: 1.35.2.1; previous revision: 1.35 done Checking in DomProvider.java; /cvs/visualweb/designer/src/org/netbeans/modules/visualweb/api/designer/DomProv ider.java,v <-- DomProvider.java new revision: 1.9.2.1; previous revision: 1.9 done Checking in SelectionManager.java; /cvs/visualweb/designer/src/org/netbeans/modules/visualweb/designer/SelectionMa nager.java,v <-- SelectionManager.java new revision: 1.38.2.1; previous revision: 1.38 done Checking in WebForm.java; /cvs/visualweb/designer/src/org/netbeans/modules/visualweb/designer/WebForm.jav a,v <-- WebForm.java new revision: 1.142.2.1; previous revision: 1.142 done Checking in InSyncServiceProvider.java; /cvs/visualweb/insync/src/org/netbeans/modules/visualweb/insync/InSyncServicePr ovider.java,v <-- InSyncServiceProvider.java new revision: 1.2.14.1; previous revision: 1.2 done Checking in ModelSet.java; /cvs/visualweb/insync/src/org/netbeans/modules/visualweb/insync/ModelSet.java,v <-- ModelSet.java new revision: 1.9.2.1; previous revision: 1.9 done Checking in faces/refactoring/FacesJspFileMoveRefactoringPlugin.java; /cvs/visualweb/insync/src/org/netbeans/modules/visualweb/insync/faces/refactori ng/FacesJspFileMoveRefactoringPlugin.java,v <-- FacesJspFileMoveRefactoringPlugin.java new revision: 1.3.2.1; previous revision: 1.3 done Checking in faces/refactoring/FacesJspFileRenameRefactoringPlugin.java; /cvs/visualweb/insync/src/org/netbeans/modules/visualweb/insync/faces/refactori ng/FacesJspFileRenameRefactoringPlugin.java,v <-- FacesJspFileRenameRefactoringPlugin.java new revision: 1.3.2.1; previous revision: 1.3 done Checking in jsf/SourceMonitor.java; /cvs/visualweb/insync/src/org/netbeans/modules/visualweb/insync/jsf/SourceMonit or.java,v <-- SourceMonitor.java new revision: 1.1.18.1; previous revision: 1.1 done Checking in models/FacesConfigModel.java; /cvs/visualweb/insync/src/org/netbeans/modules/visualweb/insync/models/FacesCon figModel.java,v <-- FacesConfigModel.java new revision: 1.1.4.1; previous revision: 1.1 done Checking in models/FacesModelSet.java; /cvs/visualweb/insync/src/org/netbeans/modules/visualweb/insync/models/FacesMod elSet.java,v <-- FacesModelSet.java new revision: 1.5.2.1; previous revision: 1.5 done
Sandip, thanks for all your fixes here. It works much better now, at least user's perception is better. I think we need to do more in this area for NB 6.0 FCS, but for M9 it's enough.