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

[Dale Henrichs via Glass]

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.

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

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

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

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

Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150706/67c745cd/attachment.html>