[Glass] Lots of seaside objects not being GCed (need gemstone advise)
Mariano Martinez Peck via Glass
glass at lists.gemtalksystems.com
Mon Jul 6 14:35:02 PDT 2015
While I keep searching... I have a couple of question/findins
1) ObjectLogEntry initialize DID get rid of many things while
ObjectLogEntry emptyLog did not.
Former does " ObjectQueue := RcQueue new: 100." while latter does "
self objectQueue removeAll. "
So..could it be that in case of a RC collection, removing elements is not
the same as building a new collection? could the RC hold to some stuff we
don't want to?
2) Could it be that some objects get GCed ONLY after a second MFC is run? I
know it sounds weird, but in Pharo it was like that (not sure if still)...
to be really sure you had to run it 3 times (this was due to #finalize and
that part of GC done in 2 steps)
3) #allInstances can include instances already for GC? In other words, if I
run MFC and then I do #allInstances... would I get those that were marked
as GC (until reclaim happens)? I ask this in order to know if I should run
a #reclaimAll for my tests I am doing...
Thanks in advance,
On Mon, Jul 6, 2015 at 4:28 PM, Mariano Martinez Peck <marianopeck at gmail.com
> wrote:
>
>
> On Mon, Jul 6, 2015 at 2:33 PM, Dale Henrichs via Glass <
> glass at lists.gemtalksystems.com> wrote:
>
>> Mariano,
>>
>> I've read over your other messages and I guess you are still struggling
>> to clean these guys up ... Rest of my comments in line.
>>
>>
> Hi Dale.
> Thanks, I answer inline.
>
>
>> Dael
>>
>> On 07/03/2015 08:22 PM, Mariano Martinez Peck via Glass wrote:
>>
>> Hi guys,
>>
>> Sorry to bother but I started to find many instances of things I think
>> I should not have.... I have a stone that nobody uses since a couple of
>> hours (so I am sure all sessions should have been expired). I have run this
>> code to clean:
>>
>> ObjectLogEntry emptyLog.
>> WAGemStoneMaintenanceTask maintenanceTaskMarkForCollect performTask: 0.
>> WAGemStoneMaintenanceTask maintenanceTaskExpiration performTask: 0.
>> System beginTransaction.
>> SystemRepository reclaimAll.
>> SystemRepository startNewLog.
>> System commitTransaction.
>>
>> Then...I check some #allInstances size and I get this:
>>
>> DpWebSession allInstances size 32
>> WACallbackRegistry allInstances size 217
>> JQueryClass allInstances size 16519
>> WACache allInstances size 35
>> WAApplication allInstances size 3
>> WARenderVisitor allInstances size 217
>> WARenderContext allInstances size 217
>> WAHtmlCanvas allInstances size 909
>> .....
>>
>> Right off the bat, my observation is that this doesn't seem like a
>> lot of uncollected objects, presumably you churn through a lot more
>> sessions than this on a regular basis, so these objects appear to be the
>> exception instead of the rule...
>>
>
> Of course. All those numbers are in a system which didn't receive a single
> request in a whole day. And this is the results after all the cleanings I
> could do. So this is why I expect to have zero instances of those (meaning
> .. no zero, but much less in the real system that what I have now),.
>
>
>>
>>
>> (just as some examples).
>>
>> The good news is that ALL the sessions do look expired:
>>
>> (DpWebSession allInstances select: [ :each | (each instVarNamed:
>> 'parent') isNil ]) size 32
>>
>> (expired sessions have a nil 'parent').
>>
>> One of the interestings that came out of the Larry's "ordeal", is that we
>> found a bug in WACache>>gemstoneReap, where an error while running this
>> method can result in objects getting stuck in the WACache. Basically
>> objects are marked as expired in the WARcLastAccessExpiryPolicy, but due to
>> the error, they may not be removed from the objectsByKey and keysByObjects
>> dictionaries ... thus keeping them alive "forever".
>>
>> If you check your maintenance vm logs, you might find an error with
>> WACache>>gemstoneReap (Almost Out of Memory is how we found the bug) in
>> Larry's case.
>>
>
>
> I grep but I found no error in my maintenance logs.
>
>
>
>>
>> Since you have so few sessions, we can test whether the object leak is
>> due to this bug:
>>
>> | sessions |
>> System abortTransaction.
>> sessions := WASession allInstances
>> select: [ :each | (each instVarNamed: 'parent') isNil ].
>> System abortTransaction.
>> WAApplication allInstances
>> do: [ :app |
>> | cache keysByObject |
>> cache := app cache.
>> keysByObject := cache instVarNamed: 'keysByObject'.
>> sessions
>> do: [ :session |
>> (keysByObject includesKey: session)
>> ifTrue: self halt ] ]
>>
>> If you get a halt running the above, then you've been bitten by the bug
>> and you you need to arrange to remove the session objects from both dicts.
>> See WACache>>gemstoneReap for example code ...
>>
>
> I did not get a Halt in above code.
>
>
>>
>> If the WASessions are not stuck in a WAApplication, then it's likely that
>> you have some accidental reference to the WASession objects and you'll have
>> to trace the reference path back to a persistent root using
>> Repository>>findReferencePathToObject: .. this method only returns one
>> reference path... In 3.2 we've created
>> Repository>>findAllReferencePathsToObject: that finds and returns all of
>> the reference paths (in a pinch you could upgrade your repository to 3.2.6
>> just to run the aalysis) ...
>>
>> [1] https://github.com/GsDevKit/Seaside31/issues/68
>>
>
>
> Yes, in fact, earlier today I tried #findReferencePathToObject: with
> (MySessionSubclass allInstances any) and guess what????
> I get an array of only 2 entries, first element is target object and
> second element is false. Reading method comment says it means there is no
> path to that object. WTF!!!! so then why they do not go away??? As said, I
> do run MFC, I do run #reclaimAll... so..... *in which scenario would I
> hold into instances (and in fact found via #allInstances), yet
> #findReferencePathToObject: would say there is no path?*
>
>
>>
>>
>> However...I cannot explain why I still have all that garbage above if
>> all sessions are expired. Is that normal? I would expect to have nothing.
>>
>> It's not normal:)
>>
>
> That's cool to hear. So...even if those are little number of objects, this
> gives me a small scenario of the real system. If this stone has not
> received a single request in hours, then I should get ZERO instances of
> those :) Cool.
>
>
>>
>>
>> The worst is the WACallbackRegistry which then refer to closures and
>> contexts of my callbacks, which could refer to large amount of temp data
>> (like lots of XML objects...).
>>
>> Is this normal? Any hint how can I get rid of those?
>>
>> WACallbackRegistry instances are referenced from the WASession instance
>> via the `continuations` WACache ... if you get rid of your WASession
>> instances you'll get rid of the WACallbackRegistry instances.
>>
>>
> Ok...
>
>
>
>> Dale
>>
>> _______________________________________________
>> 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/20150706/396079e8/attachment-0001.html>
More information about the Glass
mailing list