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

Tue Aug 25 13:57:39 PDT 2015

On Mon, Aug 24, 2015 at 6:48 PM, Dale Henrichs via Glass <
glass at lists.gemtalksystems.com> wrote:

> 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
> ....
>

Hi Dale/James,

Thanks for your answer. I do understand that a daily cleanup of those
doesn't make sense in most of the cases. However, I've been thinking and I
think I mine it does make sense. We deploy in Linode, were we have SSD
disks and the disk space is NOT very big normally. Also, in the same linode
we run a couple of stones. In addition, we keep daily backups of each
stone. And finally, we have some background process that end up
adding/editing lots of stuff from RC collections. Something we have
migrations etc... So if I can automagically do this and forget about this
in the future, then better. Otherwise I will be again fighting with objects
not being GCed.

So the size of the repository is a bit more important for me than the
average.  So...I just measured in a typical repository we have, the time to
clean all those RC classes while all seaside gems are down and it's only a
minute. Furthermore, it helps to recyle gems. So...I very much prefer 1
minute down in favor of RC cleaning and gem recycles.

But I understand this is uncommon for more cases. BTW the code I am running
at daily cleanup is this (with all seaside and background jobs gems down):

| array |
System commit.
array := (SystemRepository listInstances: { RcQueue. RcIdentityBag.
RcCounter.}).
(array at: 1) do: [:each | each cleanupQueue].
(array at: 2) do: [:each | each cleanupBag].
(array at: 3) do: [:each | each cleanupCounter].

It may help others with the same scenario as me.

>
>
> 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> 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
>
>
> _______________________________________________
> Glass mailing listGlass at lists.gemtalksystems.comhttp://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>

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