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

[Dale Henrichs via Glass]

On 07/06/2015 03:31 PM, Mariano Martinez Peck wrote:
>
>>
>>             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:
>

I guess we could have inferred that this was true, once the reference 
paths came back clean ...

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