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

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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

On Wed, May 7, 2014 at 2:14 PM, Dale Henrichs <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--
Mariano
http://marianopeck.wordpress.com