Bugzilla – Full Text Bug Listing
| Summary: | [repo] [ui] load composite repos eagerly | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Susan McCourt <susan> |
| Component: | p2 | Assignee: | DJ Houghton <dj.houghton> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | agcattle, dj.houghton, irbull, jeffmcaffer, john.arthorne, overholt, pascal |
| Version: | 3.5 | ||
| Target Milestone: | 3.5 M7 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Susan McCourt
*** Bug 258962 has been marked as a duplicate of this bug. *** Specific comments from duplicate bug: > Currently, composite repositories lazily load their children. However, it is my > understanding that part of the contract with UI is that a repository must be > finished loading before it can be displayed for efficiency reasons. However, > I'm worried that loading all children at the composite's load time and storing > them as IRepostiory objects might have a greater chance of leading to > synchronization issues than loading them right before use as this would move > them outside of the RepositoryManager. > > This results in two questions: > 1) What does it mean for a composite repo to be loaded? Just the repo or the > repo + children? > 2) How should composite repos handle the failed loading of a child? > > Currently we log the failure and just continue with the next repo. While this > increases robustness, it leaves us int he situation where the same repository, > without changing it's own content, which have different results each time a > method such as "getArtifactKeys()" is called depending on what children are > loaded. Perhaps we create a property which says whether or not we care? > The lazy loading strategy could kill the performance in the UI, especially for filtering. When we filter the available software list, we first load all repos in the background and then switch the list to synchronous retrieval (rather than async fetch). This allows us to use existing filtering support in platform UI. BUT...this technique assumes that no major time bombs are lurking after the repo load. In 3.4 we had a similar "surprise" late in the release cycle when the NLS externalization code loaded repos in the UI thread, resulting in pretty horrible hangs. I see two problems: - UI needs to change assumptions and change strategy for filtering, this involves investigation of an alternate solution. (See bug 233269 comment 11). I was hoping to avoid this. - If we spend the time to work around this and have all filtering use async retrieval, in practice the user experience would be something like: - Help>Install New Software... - wait for repos to load, keep working - wizard comes up - user goes to filter something - long wait...the filter is either not showing or incomplete...where do we show the load progress in the meantime? how do we indicate that we are still getting results? User is stuck waiting again. So I think the workflows would be broken even if we fix the technical problems, because we are now making the user wait twice. My opinion is that this is a much more serious problem than a stale repo. This would also help with the consistency of artifact keys problem, because if the sub-repos are loaded up front, then the artifact keys would remain consistent until the composite repo was refreshed. We discussed this some on the p2 call. Just to summarize the technical issues in the UI: - all fetches in viewers are done using async queries, so that part of the code is robust enough to handle queries that load - the filtering is the part where we have an issue, because we put the viewer in a synchronous fetch mode to perform filtering. Today we do that by first ensuring all repos are loaded, then filtering. To do better with filtering we would need need a filtering strategy that used an accumulation approach, where items were added to the filter as fetched. The real solution for these super-large data sets is to perform the filter itself in the query. Where are we at on this issue now that we have large composite repos? Are the composite repos loading up front? If so, UI is fine. Are they lazily loading? If so, we need to determine how UI is responding/where problems are. I'm observing the following workflow problem when I have a new composite repo. Help->Install New Software... Wait for repos to load Wizard opens Wait again for "Pending..." This makes us look really dumb. We let the user keep working and then opened the wizard that was incomplete. This is unsatisfactory for both camps of users: - the ones who like to keep working while it loads will now be blocked while composites load - the ones who never wanted to wait are now tortured twice retitling bug to stand out. (In reply to comment #6) > I'm observing the following workflow problem when I have a new composite repo. > > Help->Install New Software... > Wait for repos to load > Wizard opens > Wait again for "Pending..." > > This makes us look really dumb. > We let the user keep working and then opened the wizard that was incomplete. > This is unsatisfactory for both camps of users: > > - the ones who like to keep working while it loads will now be blocked while > composites load > - the ones who never wanted to wait are now tortured twice > This workflow is different given the fix to bug 263593. In the SDK, we open the wizard immediately so we are no longer forcing the user to wait twice. Now we open the wizard immediately and then start loading in the background. In practice what this means is that the user will get a better response (little to no wait) as they switch to non-composite repos, while composite repos would always have to load and cause a wait. As usual, the worst hit is the very first time (user's first impression). We still have the "wait twice" problem when the product is configured so that the user can't change the repositories. One possible workaround in the UI would be to change the "background load" code to do a background load followed by a query of each repo. *** Bug 267852 has been marked as a duplicate of this bug. *** I've just experienced what Andrew did in bug 267852. I started with a clean workspace, freshly unzipped 20090309-1300 (with the intention of upgrading it). When I added the I-build site, the available software list said "Pending...". This means the UI was trying to load the site in the background. Good. But then the UI hung until the Pending... was replaced with content. This tells me that a code path somewhere else (perhaps getting an NLS string) was not happening in the background and was waiting for the load to complete. (In reply to comment #0) >Under the current strategy for composite > repos, the user will still have to suffer a very long "Pending..." even after > doing all background loading ahead of time. I don't know if we have cases > where we get burned in the UI thread, but it definitely affects the usability > of the workflows. It looks like we do have cases in the UI thread. I have changed the composite repository code to eagerly load its children. Closing. |