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

[Dale Henrichs via Glass]

Mariano,

The fact that there are no reference paths to the instances of 
DpWebSession means that the objects are eligible for garbage collection 
until you have run an mfc and the objects were not voted down and the 
possibleDead have been reclaimed the objects are still alive ..

So record the objIds of the 50 or so instances of DpWebSession. logout. 
do an mfc. logout. wait for the deadNotReclaimed count to drop to zero 
(you can monitor this live in statmon or by sampling the stat in a new 
session that aborts frequently)  ...

To really know what's going on, we want STN_TRAN_LOG_DEBUG_LEVEL=3 so 
that we can use the tranlogs to understand what went on if we don't see 
the expected results ...

When the deadNotReclaimed is at 0, login, greab allInstances and look at 
the oops of the new set (if any) and compare to the oops of the original 
50 ... if there are duplicates we will want to search the tranlogs for 
those oops and try to understand what went on ...

Dale

On 07/06/2015 05:36 PM, Mariano Martinez Peck wrote:
> Dale,
>
> I continue with the efforts and based on your comments I did a couple 
> of things. First, kill all seaside gems. Stop stone. Start stone again 
> (not seaside gems), and run:
>
> ((SystemRepository listInstances: { DpWebSession }) at: 1)
>
> gives me like 50 instances.. meaning there are 50 instances ON DISK. 
> Then I tried to find a path for any of THOSE:
>
> SystemRepository findReferencePathToObject: ((SystemRepository 
> listInstances: { DpWebSession }) at: 1) first
>
> But still, #findReferencePathToObject: answers an empty path.
>
> If the path is empty, then "((SystemRepository listInstances: { 
> DpWebSession }) at: 1)    " should give me zero. Correct? Because both 
> are checking on disk...
>
> So there is something I don't understand.
>
> Thanks in advance,
>
>
> On Mon, Jul 6, 2015 at 8:22 PM, Dale Henrichs 
> <dale.henrichs at gemtalksystems.com 
> <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>
>
>
>     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
>
>
>
>
> -- 
> Mariano
> http://marianopeck.wordpress.com

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