| Summary: | Eclipse 3.2 RC7 + Callisto RC4 Staging: UI frozen after clicking "finish" | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Willian Mitsuda <wmitsuda> |
| Component: | Update (deprecated - use Eclipse>Equinox>p2) | Assignee: | Platform-Update-Inbox <platform-update-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | danny, david_williams, Mike_Wilson, mlists, stmoebius |
| Version: | 3.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | obsolete | ||
|
Description
Willian Mitsuda
Ditto for 1.5.0_07, XP SP2, 2Gb RAM, Centrino Duo T2400. Better word is unresponsive. Without going into too many details, we are aware of this and it sure looks ugly. Be sure that at that point update is doing what it is suppose to be doing. This is simple but risky fix and we do not feel comfortable doing it this late. We will definitely fix this and download progress monitor in 3.2.1. (these two problems are very closely related). Branko, are there bugs that describe the work you are doing/have done? (If so, you could mark this as a duplicate of one of them.) I've seen this behaviour on Fedora Core 5, JDK 150_04, eclipse 3.2. Does this happen in M1, too? I did put some code in but i can not be sure since i fast internet connection. (In reply to comment #5) > Does this happen in M1, too? I did put some code in but i can not be sure since > i fast internet connection. > Does this depends on internet speed? When I opened this bug report, I tested it on a 4 mbps cable connection. At that point we are opening connection to the server so it has to do with round trip to the server (network and server speed at the given moment). I tried to change that code to start download monitor before we open connection but i am not it fixed your problem. That is why i asked you to try it in M1. OK, I'll try it out tomorrow as soon as M1 is declared. Branko, it works well on 3.3 M1 + Callisto final Update Site. thanks for testing it Willian. I am closing this bug as fixed. Branko, I'm so sorry to say this, but today I tested at home, with 3.3 M1 and the bug persists. My previous test was at my work machine, and I really don't know why it didn't happen (I'm completely sure the 2 tests ran on 3.3 M1). I'll try again on monday. Again, sorry for the mistake. did some changes again and tested by putting a breaking point and it works for me. This bug still occurs on 3.2.1 M20060830-0800, and 3.3 I20060830-1650. I uploaded a flash video showing this bug occuring on M20060830-0800. http://www.willianmitsuda.com/files/bug%23145247.swf Branko, I think I located what could possibly be the problem: I debugged 3.2 and the slowdown appears while stepping over DuplicateConflictsValidator.computeNewFeatures(...) method. It calls recursively computeNewFeature(...), who calls IIncludedFeatureReference.getFeature(...), that is a expensive operation because it tries to resolve the feature URL. I noticed a little pause while stepping over IIncludedFeatureReference.getFeature(...), which together with the recursive approach could be getting into this noticeable GUI unresponsiveness. Please, let me know if you need some more specific test. The Eclipse Update component is no longer under development, and no longer exists in the Eclipse Platform 4.x stream. If this problem still occurs in Eclipse Platform 4.2 or later, please enter a new bug report against Equinox p2. |