Community
Participate
Working Groups
Eclipse 3.4 RC2 (saw it first on M7) Steps: 1 - have a few update sites showing (the more the merrier) on the Available Software tab of the Software Updates and Add-ons dialog. 2 - Hit the Refresh button (or F5), this will collapse any nodes that were previously expanded and start the refresh work 3 - as soon as you click the Refresh button, while the refreshing is happening, quickly click on one of the sites showing and try to expand the tree with the keyboard by using the left arrow repeated times 4 - Bug: when the refresh completes, that branch of the tree you expanded will have at least multiple copies of each category. See screenshot on attachment 103035 [details].
> expand the tree with the > keyboard by using the left arrow repeated times Sorry, the right arrow key, not the left one.
Maybe a duplicate of bug 229069? Haven't tried it yet on RC3.
Yes, this is a dup. It's actually a bug in the platform UI viewer we are using, but we have workarounds in our code to minimize the chance of it happening. With RC3 it is much better. *** This bug has been marked as a duplicate of bug 229069 ***
Reopening, as Rafael says he can reproduce easily in RC3.
Marking RC4 to investigate. We know this bug can still happen, the effort was to minimize the occurrences. I will try your steps to assess how readily we think a user will hit this, but chances are we will not attempt to address this any further. The real fix is using a different strategy for deferred fetch (bug #233269)
Just went back to confirm it was that easy to reproduce and other than the first couple of times I tried yesterday before I commented here, I actually couldn't reproduce it a single time afterwards. The way the tree is populated makes it harder for me to perform the actions I described in the other bug report. And even when I can accomplish them, the result is fine, with no duplicates.
In this bug report, I meant.
Thanks for the update. I suspect you could make it happen again if you opened the "manage sites" dialog and deleted all of the unchecked sites. The problem is easier to reproduce when you are adding sites which in turn add more sites.
removing milestone. I was able to reproduce this the very first time I connected to the tptp update site when I disabled the Ganymede site, enabled the tptp update site, hit OK, and then expanded another site. When the tptp site showed up and expanded, I saw the duplicates. However we are through trying to limit the conditions for getting this bug, the next course of action is to replace the DeferredTreeContentManager with something better suited for our needs. Keeping this bug alive for now so we can retry the cases once we have a replacement strategy.
*** Bug 240472 has been marked as a duplicate of this bug. ***
*** Bug 232485 has been marked as a duplicate of this bug. ***
fixed in HEAD >20081007 What I really needed was some time away from this one ;-) While working on UI workflow/code reorg, a very surgical workaround/cache occurred to me for our remote model elements. We now do not add children to any element collectors if we already have done so. We always fetch children, but before adding to the collector we check whether we already have done so. On a complete repo refresh, we'll get new model elements, so they'll be added again, but only once. I've been banging on these scenarios quite a bit while working on UI workflow changes and have not seen the problem. I'll verify again once all this gets into a build.
(In reply to comment #12) > fixed in HEAD >20081007 > What I really needed was some time away from this one ;-) > > While working on UI workflow/code reorg, a very surgical workaround/cache > occurred to me for our remote model elements. We now do not add children to > any element collectors if we already have done so. We always fetch children, > but before adding to the collector we check whether we already have done so. > > On a complete repo refresh, we'll get new model elements, so they'll be added > again, but only once. Or so I thought. There is a timing problem here, whereby the viewer input is replaced before the repo refresh completes. In the 3.4.2 candidate build, this causes bug #262044. Not sure what the ramifications are yet in the 3.5 stream, but I'm reopening this bug to examine this.
*** Bug 266984 has been marked as a duplicate of this bug. ***
I was kind of torn about what to do here. The patch has been in since 10/7/2008 and we haven't seen the duplicate problem, nor have we seen the problem that occurred with the patch in the 3.4.2 stream (bug #262044). So I was leaning toward letting sleeping dogs lie, and leaving the patch in. However I do understand a theoretical timing sequence where the patch could cause empty results (bug 262044 comment 3). Also, with the patch on 3.4.2 it was possible to recreate exactly the condition for the worse failure (empty list), while it was never guaranteed to get the original failure (duplicates). Since the patch was proven to cause problems worse than the symptom, I am pulling it out. I have been running without the patch for several days now with fresh builds/repo lists and have not seen the original problem. The entire code path regarding repo loading, opening the UI, and handling the repo events has changed since 3.4, so I'm not sure it's even possible to see the original problem now. The risk is that we see the reappearance of duplicate items. We shall see. I think we need to flush the problem out if it's still there, which requires wider usage. Backed out the collect cache in HEAD >20090415. Marking bug fixed, but it should be noted that we haven't actually fixed the problem, we just believe that the timing sequence that caused it cannot happen anymore and the cache that attempted to prevent it could cause worse problems.
