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 [email protected] tel +49 941 698484-35 fax +49 941 698484-99 mobile +49 171 5576498 =================================== SELBSTDENKER AG - No Vision Too Far Gesandtenstraße 10 93047 Regensburg [email protected] http://www.selbstdenker.ag Niederlassung: Regensburg Handelsregister: Regensburg HRB 7860 Vorstand/CEO: Stephan Fürnrohr Vors. des Aufsichtsrates/Chairman of the board: Dipl. Betriebswirt (FH) Richard Sibinger _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
