Summary: | Consumer objects not being released | ||
---|---|---|---|
Product: | z_Archived | Reporter: | Miles Parker <milesparker> |
Component: | Mylyn | Assignee: | Miles Parker <milesparker> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | major | ||
Priority: | P2 | CC: | steffen.pingel |
Version: | unspecified | ||
Target Milestone: | 2.0.1 | ||
Hardware: | Macintosh | ||
OS: | Mac OS X | ||
Whiteboard: |
Description
Miles Parker
2013-06-11 00:16:24 EDT
I've figured out the pattern now. Each time you manually refresh a review, one more patch set is added for a given patch set. This means that we're not disposing of reviews properly. I believe this issue is incidentally fixed in https://git.eclipse.org/r/#/c/13829/5/org.eclipse.mylyn.gerrit.core/src/org/eclipse/mylyn/internal/gerrit/core/remote/GerritReviewRemoteFactory.java Line 252, but I'm going to test that out to verify. (In reply to comment #1) > I've figured out the pattern now. Each time you manually refresh a review, one > more patch set is added for a given patch set. This means that we're not > disposing of [reviews] properly. Correction: [Review PathSet consumers] This is a more important issue than first thought. We really need to release consumers in every case. Otherwise, the remote objects and model objects are never released out of memory, which is obviously not a good thing. I'm going to run some memory profiling to ensure that we aren't doing anything else that could have memory impacts. Miles, please ensure that the assignee is set properly when closing bugs. Thanks! Sorry, I swear I've been checking this before resolving. I don't know how I keep missing it. . (In reply to comment #7) > Sorry, I swear I've been checking this before resolving. I don't know how I keep > missing it. Ahah! I figured out what has been going wrong with my workflow that kept screwing this up. I typically check "Accept (Change Status to Assigned)" assuming that changes the Assignee to myself. But it doesn't -- it just sets the bug status to Assigned (e.g. Triage). Which is totally confusing because a) you're "accepting" for someone else and b) how can it have a value for Assigned to: if it was never Assigned? Anyway, it shouldn't happen again. |