[Glass] Lots of seaside objects not being GCed (need gemstone advise)

[Mariano Martinez Peck via Glass]

Dale,

I have continue analyzing this in other stones and after some testing it is
clear that some sessions (the size would depend on the system usage) are
NOT GCed unless I shut all seaside gems down or cycle them. Originally I
was having  GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE on 90% and I was cycling
seaside gems once a day as part of GC. Then, I changed it to 100% and stop
restarting gems. Now...it COULD have happened that I did not restarted all
gems since I modified the GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE and so, the
system was still running with 90% and yet I was not restarting seaside gems
anymore. That could explain why I hold onto some instances, right?  Another
possibility is the "stale reference" you mention below. *I continue
answering below:*


> Good point. Thanks. I will remember it for next time: each time I am
> dealing with this kind of stuff: cycle all seaside gems first!
> Thanks. BTW, my GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE is 100% now to avoid
> having to cycle gems.
> I will continue with the tests with cycling/killing the gems... but....
> continue reading below...
>
> Do you also have the marksweep guy running?
>

The guy that every 30 minutes perform the "System
_generationScavenge_vmMarkSweep."?  Then yes. Why you ask? how this guy
could affect? He does not hold any seaside session as far as I know...i
simply sends "System _generationScavenge_vmMarkSweep.". Could it be that
the #wait: freezes the gem and therefore does not answer the the voting?

Mmmmm now I read in the sysadmin guide: *"Gems do not vote until they
complete their current transaction. If a Gem is sleeping or otherwise
engaged in a long transaction, the vote cannot be*
*finalized and garbage collection pauses at this point. Commit records
accumulate, garbage accumulates, and a variety of problems can ensue."*

Uffff maybe since this guys practically sleeps all the time and yet does
not do a commit nor abort in each iteration of the loop...maybe this guy is
preventing the vote?

Even more......the sysadmin guide also says: *"If a committed object in the
pom area has been modified, it is copied to the old area if a scavenge
occurs before the change is committed."*


If it is not that ...maybe you asked because....if it happened that I
modified the session (by any seaside request) and the
_generationScavenge_vmMarkSweep happened before the request processing
finished, then the session would have been moved to "old" space? But even
in this case, when the request processing finishes, it would commit the
"modified persistent object" (seaside session)...



> GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE only dumps the pomgen on the floor ... a
> stale direct reference to one of these in the the TOC can also keep these
> guys alive ... I think that was why I marveled in the earlier message about
> it only being 32 instances ... with the referencePath method not finding
> anything you should be able to declare a victory:)
>

What do you mean by a stale direct reference?

Thanks


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150707/94de59cd/attachment.html>