[Glass] WAApplications, WASession, WAExceptionFilter etc not being GCed unless gems down

[Dale Henrichs]

Mariano,

For the particular scenario described in the bug, restarting the gems
should be sufficient. I don't recall the details of what `reset` does, but
if it stops and restarts all gems including the maintenance vm, then that
should be sufficient to clear out stale references ...

Given that the objects get gc'ed when gems are shut down, implying that the
voting is the culprit, I am suspicious that there is a subtle difference in
your procedure that leads to the objects being kept alive when you use
`reset` ...

For example if you are keeping a gem or topaz session alive across the
seaside gem `reset` then the living gem could be the culprit, especially if
sometime it _it's_ past it obtained a reference to the object ...

Soooo, you need to describe in fine detail (accounting for every
gem/topaz/vm that is started stopped) the steps that you take ...

Also if during the seaside gem startup sequence there is an allinstances
run for some reason then _that_ might explain the phenomenon you are seeing
...

Dale



On Wed, May 7, 2014 at 11:56 AM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

>
>
>
> On Wed, May 7, 2014 at 2:14 PM, Dale Henrichs <
> dale.henrichs at gemtalksystems.com> wrote:
>
>> Mariano,
>>
>> This sounds like a case where the maintenance vm and/or seaside gems are
>> hanging into these instances[1].
>>
>> Basically gems can end up having references to objects in their "head"
>> that cause the object to be kept alive through MFC cycles. If the object is
>> in the "head" of a vm, then technically a reference could exist in temp
>> space and that reference from temp space could be hooked into the
>> persistent root so it just isn't safe to allow gc of such objects. If you
>> have seen references to voting in relation to MFC, then the otherwise dead
>> objects are being voted down ...
>>
>> You can use GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE to somewhat control the
>> situation. The setting controls what percentage of persistent references
>> are pruned prior to vote ... for GLASS, the default is 90, I think it can
>> be set higher (look in $GEMSTONE/data/system.conf for the allowed limits in
>> your version).
>>
>> Since the objects finally go away when you shut down the gems (recycling
>> the stone is not necessary), then this is pretty much the issue.
>>
>> Some folks recycle all of their gems on a regular basis (don't forget the
>> maintenance vm).
>>
>
>
> Thanks Dale. There is still something I don't understand. Instead of
> shutting down all gems and then run MFC, I tried resetting the gems, that
> is, the 'reset' option of 'runSeasideGems30', and then run MFC. This did
> NOT solve the issue!  So the workaround is not to simply restart gems and
> run MFC, but instead, kill gems, run MFC, once ready start gems again. Is
> that expected or I may be under a difference scenario?
>
> Thanks,
>
>
>
>>
>> Dale
>>
>> [1] http://code.google.com/p/glassdb/issues/detail?id=136
>>
>>
>> On Wed, May 7, 2014 at 9:48 AM, Mariano Martinez Peck <
>> marianopeck at gmail.com> wrote:
>>
>>>  Hi guys.
>>>
>>> I am cross-posting mailing lists since I am not sure where the problem
>>> is. I have a script (actually some methods) that I execute each time I want
>>> to "deploy" my app. Basically, it does some cleaning and set by root class
>>> as a seaside app. The problem right now is that I have been calling this
>>> script many times, but now I discover I still have lots of WAApplications
>>> and sessions hanging around that should not be there. The app should be
>>> registered only once, and I should have ONE instance of WAApplication with
>>> my root class.
>>>
>>> Same code DOES work in Pharo correctly. In GemStone, I have run the
>>> following:
>>>
>>> | handlerNames |
>>> handlerNames := WADispatcher default handlers collect: [ :each | each
>>> name ].
>>> handlerNames do: [:each | WAAdmin unregister: each].
>>> WAAdmin clearAll.
>>> "GsDeployer new doBulkMigrate.
>>> SystemRepository markForCollection."
>>> WAAdmin defaultDispatcher handlers. "aDictionary( )"
>>> WADispatcher default handlers. "aDictionary( )"
>>>
>>> (MyWebSession allInstances collect: [:each | each continuations
>>> expiryPolicy configuration at: #cacheTimeout ]) size " 12" .
>>> (WAApplication allInstances select: [:each | (each preferenceAt:
>>> #rootClass) name = #MyRootTask ]) size "16".
>>>
>>> So as you can see I have 12 instances of MyWebSesison, 16 instances of
>>> WAApplication etc. There was no way I can get rid of them. I even tried
>>> executing #doBulkMigrate and #markForCollection.
>>>
>>> Finally, I turned off the stone, start it again but do not start seaside
>>> gems again, and execute the above code. Finally, it worked.
>>>
>>> So my question is...is this expected? or should I be able to get the
>>> GCed even without restarting the stone? In any case, do I have to kill all
>>> seaside gems in order to have these GCed?
>>>
>>> Thanks in advance,
>>>
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>> _______________________________________________
>>> 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/20140507/92535e82/attachment.html>