Just do this and it'll fix the "failed to find a snapshot for EO with Global ID" error?
setRetainRegisteredObjects( true );
Bravo!
Calven Subject: Re: failed to find a snapshot for EO with Global ID
Date: 21 June, 2012 5:45:38 AM EDT
Hi folks,
Am 16.06.2012 um 02:20 schrieb Ramsey Gurley:
On Jun 14, 2012, at 3:24 PM, Mike Schrag wrote:
So it would seem that the nested ECs are sneaking past this fix and causing havoc. I'm still not sure what about garbage collection triggers this, but I've updated ERXEC so that nested ECs check to see if any of its parents are saving before processing notifications. The test passes with that change in place.
The GC + child editing context thing sounds like a problem we ran into a couple years ago ... From my notes:
"The essence of the problem is that EO's track retain count as an ivar. This retain count records how many nested ec's contain that EO as well, because they share a snapshot (with refcount = 1). If, however, the parent EO gets garbage collected while the nested EC version of it is still alive, the parent EO's retain count disappears and it throws off the snapshot ref counting.
We talked about this and bounced around a couple ideas, but ultimately the one that seemed to have the least side-effects was to track the retain count in the EC rather than the EO. This patch provides an impl of that concept -- retain count is now removed from EO and pushed up into a dictionary in the EC. Now even if the underlying EO gets GC'd, the retain counts won't be lost."
ms
Looks like I'll need to investigate this further. My fix doesn't cover all the snapshot issues we are having :-/ After a quiet Thursday, we got a few today. Finding a way to reproduce these errors is difficult.
All right, I had those snapshot exceptions ocurring several times each day in a high-concurrency single-instance app I am maintaining, for years, So I followed this discussion very attentively. I always suspected a bug in EOF, and although I have a few cases of nested EOEditingContexts in my app, I never thought of *that* being the trigger. Instead, I spent whole days searching for anything that might violate one the EOF commandments, but to no avail.
Then, I read this thread, and I included the following call in my own EditingContext subclass' constructors:
setRetainRegisteredObjects( true );
I realize this would strictly only be needed for ECs that have children, but I cannot generelly make that distinction in advance in my case, and as soon as the EC holds EOs, you cannot change that setting any more. So I set this on each and every EC. Turns out, since I don't use session.defaultEditingContext() and all my editingcontexts are short lived (see Chuck's editingcontext talk a few years ago), memory consumption didn't go up that much, like 10 GB previously and 11 GB now on average (machine has 48 GB, so no big deal).
And guess what? The damn' exceptions are GONE! :-)
I have this running since last Monday now, so I'm pretty sure that's a final verdict. So, thanks everyone for this discussion, that was a major breakthrough in app stability for me.
See you in Montréal next week!
--
Maik Musall
|