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.
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?YepIs this a bug in ERXObjectStoreCoordinatorSynchronizer,YepNopeor am I just doing things incorrectly?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.
TroyMy 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