Bugzilla – Full Text Bug Listing
| Summary: | Setting build path took 8 minutes | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP Webservices | Reporter: | Patric Rufflar <patric> | ||||||||
| Component: | jst.ws.jaxws | Assignee: | Danail Branekov <danail.branekov> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | Shane Clarke <shane_clarke> | ||||||||
| Severity: | critical | ||||||||||
| Priority: | P3 | CC: | danail.branekov, keith.chong.ca, thatnitind | ||||||||
| Version: | unspecified | ||||||||||
| Target Milestone: | 3.4 M1 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Patric Rufflar
Created attachment 197110 [details]
thread dump
Created attachment 197114 [details]
Profiling results which proves the problem
This appears to be in jax-ws code: org.eclipse.jst.ws.jaxws.dom.runtime.persistence.sync.AbstractModelSynchronizer.processCompilationUnit(AbstractModelSynchronizer.java:106) Patric, what jdk are you using? Could you please provide more detailed steps on how to reproduce the problem? You clicked OK in which dialog? Keith, I am using the most recent JDK 6 Update 25 for running eclipse. I openend the project properties in a dynamic web project, Java build path, changed to the libraries tab, and changed jdk from version 5 to jdk 6 and I changed the application server runtime from tomcat 5.5 to tomcat 6 and clicked at "OK". Patric, Is it possible to provide a sample project via which the issue can be reproduced? Do you have other projects in the workspace? Thanks! Regards, Danail *** Bug 347966 has been marked as a duplicate of this bug. *** Hi Patric, if possible, could you please attach your project or perhaps a reduced test case? Hi Danail/Shane, any updates on this? From the profile results, could you figure out what is holding the workspace lock? Hi Keith, I was unable to reproduce the issue locally and that's why I asked for a sample project to play with Looking and the thread dump and profiling results I would say that JAX-WS model updater spends quite some time building the syntax tree (AST) of compilation units. With regards to this I could assume that there are lots (like tens of thousands) of java classes in the workspace, or there are classes with huge content. Or, alternatively, there might be some dramatic performance degradation in the AST parser but I don't think that this is the case Regards, Danail Thanks Danail. Patric, could you please attach your project or workspace? Hi Patric, Could you please tell us how many classes you have in your project and also if they are huge? Danail, could you try creating one class and then copy/duplicate it many times to see if you can reproduce the problem? Hi Keith, sorry that it took a while to answer. Unfortunately I cannot provide the project on which I saw this issue. It's a relativly large project, it consists of about 4000 classes with approx. 1 million lines of code. Some classes maybe larger (let's say up to 10000 source lines) but most of them should be around 200-2000 lines. Created attachment 200403 [details]
Test project with 500K LOC
Attaching test project with 500K LOC (there's a limit on attachment sizes) to help reproduce the problem.
Can copy and paste the packages in the project to increase LOC.
Following the WTP Weekly status call i'm updating the target milestone and assignee for this. Assigning to you Danail. Thanks for the sample project, Shane! I have played around with a profiler and found out some interesting facts: 1. The WS model load takes the same amount of time as pure java build. IMO this indicates that model loading is in a good shape with regards to performance. After all, the load process needs to parse all compilation units in order to find whether there are web services 2. The WS model is a memory one and therefore upon Eclipse start it needs to be loaded. This is implemented as a workspace job with workspace root as a scheduling rule in order to guarantee model consistency. Effectively, this means that upon startup the user has to wait as much time as it would take to perform a workspace clean build. BTW, Shane, this is the cause of the increased startup time you mentioned in a mail a couple of days ago 3. The JDK change fires a project opened event which results in project compilation units being completely re-parsed. This is the root cause of the issue reported here As a solution to (1), (2) and indirectly to (3) we could take the model load process out of a workspace job thus preventing the user from waiting in both eclipse start and JDK change use cases. Such a change however requires some time to implement. Regarding (3) it is interesting to find out why JDK change fires "open project" event given that no projects are closed or opened. I have updated the WS DOM load behaviour in HEAD and released the change as v201108161458 The new things are: 1. WS DOM is not loaded on eclipse startup 2. The model load is performed when requested for the first time via expanding the "JAX-WS Web Services" node in the project explorer. The very load process is performed in a background job which can be interrupted by the user 3. If the model load is interrupted, the load routine would be restarted when the user expands "JAX-WS Web Services" node again Impact from users' pojnt of view: - The solution above provides that the Eclipse startup time is not increased by the model load - If the model is not loaded, changes in the projects are not handled by the WS model listener. As a result, changing the build path as Patric described would happen faster as WS model load will not take place However, if the model is loaded (i.e. tracks changes in projects), changing the project classpath (via e.g. changing project JDK) would still cause the model reload. The reason for this is that a classpath change brings new project dependencies which invalidates the current model state and therefore model reload is required. A model reload takes approximately same amount of time as the one needed for a full project rebuild. Regarding point (3) of my previous comment - setting build path does not fire project-open event. The implementation of the resource change tracker in the DOM model enforces model reload via simulating project closed and then opened. Patric, do you think that this solution is OK for you? You can test it once a new WTP 3.4 integration build is available or you can simply checkout webtools/webservices code and test in a runtime workbench Thanks! Danail Hi Patric, Could you please try out Danail's fix? Marking as resolved. Fix released to HEAD and available in 3.4.0 builds. http://download.eclipse.org/webtools/downloads/ Patrick if you're happy with the solution in the 3.4.0 build and need the fix in the 3.3.1 maintenance build could you please open a separate bugzilla for that? Please do that soon if needed as we will need PMC approval to apply the fix in 3.3.1. |