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

[Mariano Martinez Peck via Glass]

>
>
>>
>>>
>>> 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.
>>
>> Did you replace `WASession allInstances` with DpWebSession?
>>
>
>
> hahahahaha how can I keep my respect after this? hahaha. Sorry. What
> another pair of eyes can do... Thanks Dale..Sorry. Having a 2 month baby is
> killing ahahah (perfect excuse!)
> OK...so yeah, it halted.
> So if I understand correct, a possible fix is what you submitted to
> https://github.com/GsDevKit/Seaside31/issues/68 ?
> As to the workaround (to remove existing ones) I am not sure what I should
> do. I guess first step is to apply above fix. Then... A simple
> WACache allInstances do: [:each | each gemstoneReap]   would not do it?
>
>

Ouch... no... It wasn't that..the Halt I got was simple because... the code
you pasted says:

  do: [ :session |
>           (keysByObject includesKey: session)
>             ifTrue: self halt
>

While it should be:

  do: [ :session |
>           (keysByObject includesKey: session)
>             ifTrue: [ Halt halt ]
>
And doing that it doesn't halt.

Damn... I need to keep hunting then...


>>
>>>
>>> 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?*
>>
>> If I'm not mistaken, #findReferencePathToObject: scans for references in
>> the repository, but does not take into account instances in a vm's memory
>>
>
> Ahhhh!!!! while #allInstances answer both!
>
>
>> ...
>>
>> At this point I don't know  whether these objects are staying alive
>> because of persistent references or because they are in a vms head and
>> being voted down ...
>>
>>
>>
>>>
>>>
>>>  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.
>>
>>
>>
>> To know with certainty whether or not an object is considered truly dead,
>> you can look at System class>>_deadNotReclaimed and see if the oops of the
>> suspect sessions are in it or not (see the comment in the method for
>> conditions of use). Barring any nasty bugs they are likely to have be voted
>> down ...
>>
>> If you set STN_TRAN_LOG_DEBUG_LEVEL=3 in your system.conf and restart
>> your stone ... it is possible to find the list of objects in the possible
>> dead set, the list of objects voted down (and the session id that voted
>> them down) and the original list of deadNotReclaimed ...
>>
>> Of course if you restart your stone then the heads of the various gems
>> will be cleared and it is likely that the objects will go away on the next
>> mfc ... Note that in 3.1.0.6, it is possible that the gem doing the mfc is
>> hanging onto some objects in it's head, so unless you logout after the mfc,
>> that might be the reason for voting guys down ...
>>
>>
> OK, thanks for this explanation.
>
>
>
> --
> 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/b9c8e579/attachment.html>