Re: Memory leak (kind of) in ERXObjectStoreCoordinatorSynchronizer

Thanks for the reply, Ramsey.

I've found that I can avoid the leak by just disabling the synchronizer and
leaving the ERXOSC pool:

ERXObjectStoreCoordinatorSynchronizer.synchronizer().setDefaultSettings(new
SynchronizerSettings(false, false, false, false));

Do you see any downsides to doing it that way, or have you found that it is
also necessary to avoid the OSC pool for other reasons?

I guess not many people are using the OSC synchronizer & pool(?) The leak
seems pretty glaring... I'm surprised more people haven't run into problems.

-- 
Troy


On Thu, Dec 27, 2012 at 2:12 PM, Ramsey Gurley <[email protected]>wrote:

>
> On Dec 27, 2012, at 12:50 PM, Troy Evans wrote:
>
> Hello,
>
> I posted this question on stackoverflow.com a few months ago:
> http://stackoverflow.com/questions/10302982/.  I've since found a little
> more information about the problem and updated the original question. The
> quick version is this:
>
> I've found that ERXObjectStoreCoordinatorSynchronizer seems to synchronize
> some things that it shouldn't and fails to clean up some things that fall
> out of scope. In the example I have in the stackoverflow question, an
> object is created, saved, and then it's EC and OSC are disposed and
> everything falls out of scope, which results in the object being removed
> from the EODatabase._snapshots array (as it should). After the snapshot is
> removed from the EODatabase instance, the synchronizer runs and adds the
> (now obsolete) EO to the other OSCs, which results in the object being *re
> *-added to the EODatabase._snapshots array, where it remains until all
> relevant OSCs are disposed.
>
> In the app I'm working on, since some OSCs stick around for the life of
> the app, the above scenario results in a memory leak with the old/obsolete
> objects hanging around in memory until the app is restarted.
>
> I suppose I could periodically locate an dispose all of my OSCs to get
> around the issue, but shouldn't it be the synchronizer's job to clean up
> obsolete objects?
>
> Is anyone else seeing this behavior?
>
>
> Yep
>
> Is this a bug in ERXObjectStoreCoordinatorSynchronizer,
>
>
> Yep
>
> or am I just doing things incorrectly?
>
>
> Nope
>
>
> Thanks,
> Troy
>
>
> I noticed this putting together the persistent session storage framework.
> jMeter tests ran fine until I turned on ERXOSC pooling. Then memory usage
> exploded as if I had no persistent sessions at all. The problem is exactly
> what you are describing. The synchronizer adds the snapshot to all the
> other OSCs but the only thing that cleans up the snapshots is the EC and it
> only cleans up its own OSC.  It's easy to demonstrate with persistent
> sessions because the snapshots are relatively big (~73Kb in my test case).
> I didn't see a way to fix it easily.
>
> My solution is to avoid the ERXOSC pool. If its a small/slow leak, you
> could schedule restarts on your instances.  You might also run multiple
> instances instead of using an OSC pool.
>
> Ramsey
>
>

------------------------------------------------------------------------------
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812

_______________________________________________
Wonder-disc mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wonder-disc