Seaside sessions not being either unregistered or GCed
Locked
Seaside sessions not being either unregistered or GCed
 
|
Hi guys,
I am having a hard time to see why my seaside sessions are not being GCed nor unregistered. First of all, when I register my app, I set a timeout. I even tried with 1 minute timeout: app cache expiryPolicy configuration at: #cacheTimeout put: 60 I put a halt in MySessionSubclass >> #unregistered (which then calls super). I have seen many seaside things around: WARenderVisitor instanceCount -> 77. WAHtmlCanvas instanceCount -> 1061. JQueryClass instanceCount -> 13492. WACallbackRegistry instanceCount -> 77. MySessionSubclass -> 12. ..... As you can see, I have plenty of memory around callbacks registries, renders, visitors, sessions etc... If I try to see which sessions were expired: MySessionSubclass allInstances select: [ :each | (each instVarNamed: 'parent') isNil ] -> #() The 'parent' instVar there is because "super unregistered" does that and I don't know another way to check if a session is expired or not. Finally, the only way I have to get rid of everything is this way: WAApplication allInstances do: [ :each | each clear ]. But then, that clears all sessions...even the active ones which I don't want. So.... how can I force the GC of all none expired sessions? And why my sessions are not receiving #unregistered ? Note also that in my example the instanceCount of MySessionSubclass is bigger than 10, because somewhere I read that Seaside would start cleaning sessions upon 10th. So.... any idea? What am I doing wrong? Thanks in advance, _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside sessions not being either unregistered or GCed
|
|
FWIW, my old stand-by is
WACache allInstances do: [ :e | e reap]. On 7/3/15 5:41 PM, Mariano Martinez
Peck wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside sessions not being either unregistered or GCed
|
|
In reply to this post by Mariano Martinez Peck
Hi Mariano,
Is this in Pharo or Gemstone? Johan
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside sessions not being either unregistered or GCed
|
|
In reply to this post by Bob Arning-2
On Fri, Jul 3, 2015 at 7:09 PM, Bob Arning <[hidden email]> wrote:
Thanks Bob, I just tried that and indeed, after doing that and a GC, it removed almost all garbage I have around and indeed, it called all the #unregistered of my sessions. So.... OK, with such code I can at least force the GC of those (which is similar to the one I was doing: WAApplication allInstances do: [ :each | each clear ].) , but... I still wonder, why my sessions are not "reap" automatically? Why they do not get the #unregistered automatically? From what I understand, they should, right?
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside sessions not being either unregistered or GCed
|
|
In reply to this post by Johan Brichau-2
On Sat, Jul 4, 2015 at 4:34 AM, Johan Brichau <[hidden email]> wrote:
Hi Johan, This particular problem is on Pharo (sessions not getting #unregisted but when forced, most garbage goes away). On GemStone I have a different one... sessions DO get #unregistered (thanks to seaside maintenance vm), BUT I still have lots of garbage around...(on Pharo they go away when sessions are manually unregistered). For GemStone I opened another thread in gemstone list. Any idea? Thanks!
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside sessions not being either unregistered or GCed
|
|
In reply to this post by Mariano Martinez Peck
look for senders of #reap. There are different
"strategies" that do this under different circumstances.
On 7/4/15 9:13 AM, Mariano Martinez
Peck wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside sessions not being either unregistered or GCed
|
|
On Sat, Jul 4, 2015 at 10:51 AM, Bob Arning <[hidden email]> wrote:
Indeed, thanks! It seems I am using the default one (since I do not specify a different one) and even I confirm this: (WACache allInstances collect: [ :each | each reapingStrategy class ]) asSet -> a Set(WAAccessIntervalReapingStrategy) And that class ends up using "WAAccessIntervalReapingStrategyConfiguration instance" which defines: describeOn: config (config integer: #cacheReapInterval) comment: 'The number of cache stores that are allowed before expired objects are reaped from the cache.'; default: 10 And still, at the very beginning of this email I showed how my sessions were not unregistered even if I had more than 10 instances around (I had 13 if I remember correctly). mmmmm getting this code: WACache allInstances collect: [ :each | each reapingStrategy instVarNamed: 'count' ] -> #(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7 2 5 0 0) tells me that maybe I am misunderstanding the #cacheReapInterval. So maybe it is not 10 sessions... but that each cache (assume one per session and one per app) would be cleared only after something was stored there at least 10 times??? mmmmmm mmmm more confused than before...
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside sessions not being either unregistered or GCed
|
|
Yes, it is per cache. What you may be
overlooking is this: the cache will be reaped every 10 (whatever)
accesses or stores. That doesn't mean there is anything
actually expired at that time, but the reap happens (doing nothing)
and the strategy's count is reset to zero. If something expires
after this reap, then it will take another 10 accesses (or whatever)
before the newly-expired goes away.
On 7/4/15 10:12 AM, Mariano Martinez
Peck wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside sessions not being either unregistered or GCed
|
|
On Sat, Jul 4, 2015 at 12:08 PM, Bob Arning <[hidden email]> wrote:
Thanks Bob for the explanation. It makes sense now. So....the last piece on the puzzle that I don't understand now is how can I hook when my session is expired. I mean... MySessionSubclass >> #unregisgtered will be called when reaped, not when expired. So...how can I hook when my session is expired (when it gives the timeout to the user saying session was expired)? Not sure if I need that, but jut wondering ;) Thanks!
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside sessions not being either unregistered or GCed
|
|
On Sat, Jul 4, 2015 at 5:29 PM, Mariano Martinez Peck
<[hidden email]> wrote: > > > On Sat, Jul 4, 2015 at 12:08 PM, Bob Arning <[hidden email]> wrote: >> >> Yes, it is per cache. What you may be overlooking is this: the cache will >> be reaped every 10 (whatever) accesses or stores. That doesn't mean there is >> anything actually expired at that time, but the reap happens (doing nothing) >> and the strategy's count is reset to zero. If something expires after this >> reap, then it will take another 10 accesses (or whatever) before the >> newly-expired goes away. >> > > Thanks Bob for the explanation. It makes sense now. > > So....the last piece on the puzzle that I don't understand now is how can I > hook when my session is expired. I mean... MySessionSubclass >> > #unregisgtered will be called when reaped, not when expired. So...how can I > hook when my session is expired (when it gives the timeout to the user > saying session was expired)? Not sure if I need that, but jut wondering ;) If I understand you correctly, either: WAHandlerTrackingStrategy >> noHandlerFoundForKey:in:context: -> WApplication >> #handleExpired: -> WAResponseGenerator >> #expiredRegistryKey. This is the preferred way, the only issue is that you don't have access to the session. Or the removalAction on the cache. I would advise against doing it here. Keep in mind the session being #unregisgtered here may not the be session of the currently active request because we do bulk reaping. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |