| Summary: | WebappManager.start(...) is taking 6 minutes to start my Web application | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jeffrey Liu <jeffliu> |
| Component: | User Assistance | Assignee: | Konrad Kolosowski <konradk> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | P3 | CC: | david_williams |
| Version: | 3.0 | ||
| Target Milestone: | 3.0 M9 | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
|
Description
Jeffrey Liu
Could you debug it further, or provide a way for us to reproduce? I do not see a problem when running help webapp. Looks like the amount of time spent in the WebappManager.start(...) method depends on the number of plugins my Web app pulls in... I've modified my Web app plugin so that it only pulls in the org.eclipse.* plugins. At this point of time, it only takes about 23924 ms to startup. However, when I started to pull in Studio plugins, that's when things started to slow down. On top of the org.eclipse.* plugins, I added one Studio plugin dependency, immediately, the startup time increased to 47228 ms. Then, I added another one, the startup time increased to 80876 ms. The next one increased the startup time to 129769 ms... Was there any changes in the way dependencies are loaded in M8 (the OSGI layer)? Is there any way to turn on tracing for the WebappManager? If you have a debug version of the WebappManager, you can send it to me, I'm willing to try it out. I don't see a way to reproduce this unless I sent you the Studio driver. Thanks. I am not sure whether this will help you debug the problem or not, but I'll mention it anyways. I've modified my Web app plugin so that it imports every single Eclipse plugins there is. Immediately, the startup time went through the roof. It has been 10 minutes now, and the WebappManager.start(...) method is still running... Thanks. I can reproduce. PluginClassLoaderWrapper has been rewritten recently to remove dependency on runtime.compatibility plug-in. PluginClassLoaderWrapper.getPluginClassPath() needs to be optimized. Fixed. Please verify in builds > 20040409. |