[Glass] RcIdentityBag holding deleted objects via instVar "components"?

Mon Aug 24 14:28:41 PDT 2015

On Mon, Aug 24, 2015 at 5:34 PM, James Foster <
james.foster at gemtalksystems.com> wrote:

>
> On Aug 24, 2015, at 1:04 PM, Mariano Martinez Peck <marianopeck at gmail.com>
> wrote:
>
>
>
> On Mon, Aug 24, 2015 at 4:49 PM, James Foster <
> 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> 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
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>

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