[Glass] RcIdentityBag holding deleted objects via instVar "components"?
Dale Henrichs via Glass
glass at lists.gemtalksystems.com
Mon Aug 24 14:48:26 PDT 2015
Mariano,
I don't think you need to clean up RcBags/RcQueues on a daily basis
unless you are running tight on space ...
If you can live with a bit of repo growth then you can do the cleanup on
a weekly or monthly basis.
You might have a pattern of daily cleanup and mfc; on a weekly basis
take a 15 minute system shutdown where you shutdown system, run single
user cleanup tasks, restart system and run mfc; on a monthly basis take
a longer system shutdown where you stop the stone, shrink extents, do
weekly cleanup ....
Dale
On 08/24/2015 02:28 PM, Mariano Martinez Peck via Glass wrote:
>
> On Mon, Aug 24, 2015 at 5:34 PM, James Foster
> <james.foster at gemtalksystems.com
> <mailto:james.foster at gemtalksystems.com>> wrote:
>
>
>> On Aug 24, 2015, at 1:04 PM, Mariano Martinez Peck
>> <marianopeck at gmail.com <mailto:marianopeck at gmail.com>> wrote:
>>
>>
>>
>> On Mon, Aug 24, 2015 at 4:49 PM, James Foster
>> <james.foster at gemtalksystems.com
>> <mailto:james.foster at gemtalksystems.com>> wrote:
>>
>> Mariano,
>>
>> What happens if you run #’cleanupBag’ on the instance?
>>
>>
>> Nothing, I just tried. 'components' answers the same and a MFC
>> does not GC those.
>
> Okay. We might have a bit more to do if you have other sessions
> logged in… Next try #’_unsafeCleanupBag’ and see if that removes
> the extra contents (see the method comments and also see
> #’centralizeSessionElements’). You should not need to do the full
> MFC to verify that they are actually gone from the RcIdentityBag.
>
>
> Hi James,
>
> This is a quick email just saying that indeed the #_unsafeCleanupBag
> did get rid of those objects. Thanks!
>
>> To manage reduced conflicts there are separate bags for each
>> possible session, one for adding and one for removing. If you
>> add in one session and remove in another then the collection
>> will not have the object because the number of removals
>> matches the number of adds. To provide the reduced conflict
>> behavior a session does not modify the cache for another
>> session unless you do a cleanup (which is documented to risk
>> a conflict).
>>
>>
>> I do not folliw. when I should send #cleanupBag? Every time I
>> remove/add? Or as part of my maintenance script?
>
> I’d suggest that #”centralizeSessionElements’ and #’cleanupBag’ be
> part of a maintenance process when other sessions are not logged in.
>
>
> I will have to read carefully the comments of those methods and see
> how to run those at maintenance scripts. I was not recycling gems
> anymore in daily cleanup (prune at 100%) ...but seems it seems I may
> have to do it again.... grrrrrr...
>
> Just quick question, do you recommend me sending such cleanup methods
> only to my DOMAIN specific RC instances or you'd better go over
> #allInstances so that to clean up as well RC classes used by other
> parts of the system (like gemstone internals, seaside, etc) ?
>
>> Also.... in the ProgGuide I found NO reference to #cleanupBag.
>
> Good point. The docs briefly mention cleanup in RcQueue but should
> discuss it for other classes. I’ll put in a docs request.
>
>
> mmmmm should I then send #cleanupMySession to RcQueue instances as
> part of my daily maintenance (like ObjectLogEntry queue) ?
> if true, same question as above...should I only clean up MY instances
> or go via #allInstances?
>
>> Where should I read more about it?
>
> Other than the docs, I’d suggest
> https://www.youtube.com/watch?v=1rb_A8hwKmc.
>
>
> Thanks James. Tomorrow I will watch this, check the code a bit more
> and read comments.
>
> Cheers,
>
> James
>
>> Thanks,
>>
>>
>>
>> James
>>
>>> On Aug 24, 2015, at 12:28 PM, Mariano Martinez Peck via
>>> Glass <glass at lists.gemtalksystems.com
>>> <mailto:glass at lists.gemtalksystems.com>> wrote:
>>>
>>> Hi guys,
>>>
>>> I use RcIdentityBag as the "collection" class for the
>>> typical storage of domain persistent objects. I am getting
>>> an issue now where I cleaned such a collection but things
>>> are not GCed.
>>>
>>> I have one object whose print string looks like
>>> "aRcIdentityBag( )" and "self size" does answer zero. However,
>>>
>>> self instVarNamed: 'components' ----->
>>>
>>> anArray( anIdentityBag( ), anIdentityBag( ), anIdentityBag(
>>> ), anIdentityBag( ), anIdentityBag(
>>> *aDpOfxPriceRepository*), anIdentityBag(
>>> *aDpOfxPriceRepository*), anIdentityBag( ), anIdentityBag(
>>> ), anIdentityBag( ), anIdentityBag( ), anIdentityBag( ),
>>> anIdentityBag( ), anIdentityBag( ), anIdentityBag( ),
>>> anIdentityBag( ), anIdentityBag( ), anIdentityBag( ),
>>> anIdentityBag( ), anIdentityBag( ), anIdentityBag( ),
>>> anIdentityBag( ), anIdentityBag( ), anIdentityBag( ),
>>> anIdentityBag( ), anIdentityBag( ), anIdentityBag( ),
>>> anIdentityBag( ), anIdentityBag( ), anIdentityBag( ),
>>> anIdentityBag( ))
>>>
>>> WTF? The collection is empty, but the internal 'components'
>>> instVar is holding the already deleted objects that were in
>>> the collection (*DpOfxPriceRepository *instances).
>>>
>>> BTW...I remember a similar issue with the ObjectLogEntry
>>> whose ObjectQueue is a RcQueue. I remembered that I was not
>>> GCing objects while I was trying:
>>>
>>> ObjectLogEntry class >> emptyLog
>>> "expect the caller to abort, acquire lock, and commit if
>>> necessary"
>>>
>>> * self objectQueue removeAll.*
>>> ObjectLog := nil.
>>>
>>>
>>> That was not GCing. Once I run #initialize instead, suddenly
>>> things got GCed. So since the code there does a #removeAll
>>> too I wonder if it wasn't the same issue. Not sure since
>>> RcQueue does not have a 'component' instVar...but just
>>> wondering.
>>>
>>>
>>> Any idea what could be wrong?
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>> <http://marianopeck.wordpress.com/>
>>> _______________________________________________
>>> Glass mailing list
>>> Glass at lists.gemtalksystems.com
>>> <mailto:Glass at lists.gemtalksystems.com>
>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>
>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150824/93c524d2/attachment-0001.html>
More information about the Glass
mailing list