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

Dale Henrichs dale.henrichs at gemtalksystems.com
Wed May 7 10:14:58 PDT 2014


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).

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140507/b252aecf/attachment.html>


More information about the Glass mailing list