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

[Mariano Martinez Peck via Glass]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150706/8056e4c2/attachment.html>