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

[Mariano Martinez Peck]

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/7e157bc8/attachment-0001.html>