Hi Maik, The snapshots are purged from the cache when an EC is disposed if no other EO in another EC is still referencing them. That is, disposing will decrement the reference count for the snapshot of the EOs in the EC. That should happen automatically when the page is garbage collecting, assuming of course there are no other references to an EC in that EC. Dispose is commonly called to speed up this process. But to do that, you need to know when you are done with the EC which can be hard in a page.
The errors you got from calling dispose may have been due to references on the page or elsewhere to EOs in the EC. Calling methods on them after their EC was disposed would result in NPE or other exceptions. Alternatives would be to call refaultAllObjects() or nulling the EC variable. This is interesting: “With the number of objects growing we observed quadratic runtime growth when retrieving objects form the snapshot cache”. That suggests that with large numbers of objects inefficiencies in the hash function (too many collisions) come into play, or there are algorithmic deficiencies in the dictionary used to store the snapshots. Neither of which would be easy to fix. Chuck From: <webobjects-dev-bounces+chill=gevityinc....@lists.apple.com<mailto:webobjects-dev-bounces+chill=gevityinc....@lists.apple.com>> on behalf of Musall Maik <m...@selbstdenker.ag<mailto:m...@selbstdenker.ag>> Date: Wednesday, January 27, 2016 at 5:38 AM To: Apple WebObjects Developer List <webobjects-dev@lists.apple.com<mailto:webobjects-dev@lists.apple.com>> Subject: Re: Instance becomes unresponsive after 12 hours Hi Dennis, thanks for your suggestions. Currently, I don't dispose of editing contexts explicitly. I had EOF errors a few years ago when I used to have dispose() calls after the final saveChanges(), so I stopped doing dispose(). (I don't recall the details.) I do however create editing contexts frequently and do only limited stuff in each one. I don't use the session editing context. So in theory, any editing context should become unreachable once the component is no longer in the page cache, and then the garbage collector should take care of it. Are you suggesting something different? And you also suggest that when I dispose() of editing contexts, the corresponding snapshots are purged from the snapshot cache? That would be new to me. Currently I don't know of a method to do that other than invalidateAllObjects() or invalidateObjectsWithGlobalIDs(). Maik Am 27.01.2016 um 10:39 schrieb Dennis Bliefernicht <dennis.blieferni...@xyrality.com<mailto:dennis.blieferni...@xyrality.com>>: Hi, On 26.01.2016, at 14:28, Musall Maik <m...@selbstdenker.ag<mailto:m...@selbstdenker.ag>> wrote: Anyway, heap sizes of up to 60 GByte are apparently not so common, at least not with WebObjects. I found a helpful article [1] about very large JVM heaps, including the hint to the Zing Azul JVM, which features a stopless garbage collector [3], but costs $8000 per server and year. In the end, we may actually be trying that if other options fail, but first I need to understand more about what's in memory. I'm currently approaching that question via JProfiler, especially to find out if that's all snapshot cache (how would I limit that in size?) or some other homemade memory leak. Just a shot in the dark (especially the regular timing makes this weird), but we have had some issues with the snapshot cache accumulating a lot of data when some editing contexts weren't disposed early on (and the referred objects thus were carried on until session timeouts may finally remove them). With the number of objects growing we observed (if I remember correctly) quadratic runtime growth when retrieving objects form the snapshot cache. As we handle a large amount of small objects, this escalated rather suddenly when the cache exceeded a certain size. In this case JProfiler should show you larger amounts of time spent retrieving objects from the snapshot cache in the Hotspots list. In our case we were able to dispose editing contexts as soon as possible, flushing the objects out of the cache and keeping retrieval time speedy. Restarting instances would in this case also keep the accumulated cruft down, this scenario would probably only match though, if a significant amount of objects come into the system shortly before or at the waiting times. Greetings Dennis -- [cid:B4A9CB32-6254-49B0-9576-C3C5EE9346A5@datacenter] ----------------------------------------------------- Dennis Bliefernicht • Backend Development T +49 40 357 3001 62 dennis.blieferni...@xyrality.com<mailto:dennis.blieferni...@xyrality.com> XYRALITY GmbH • Friedensallee 290 • 22763 Hamburg www.xyrality.com<http://www.xyrality.com/> Registergericht: Hamburg HRB 115332 Geschäftsführer: Sven Ossenbrüggen -----------------------------------------------------
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
