[Seaside] Re: Session expiration and data cleaning

[Bob Arning]

You might try

PointerFinder on: WASession allInstances first

Cheers,
Bob

On 2/26/14 2:09 PM, Jon Paynter wrote:
> ive tried WASession allInstances do: [ : item | item unregister].
> and various other permutations.
>
> Some sessions go away, but most do not.  So something else is hanging 
> onto the sessions.  Eventually I will get fed up with my bloated image 
> and reload everything from source.
>
> If there is a reasonable way to track what is holding onto the 
> sessions i can track that down and either fix my own bugs, or submit a 
> new one here to the list.
>
>
>
> On Wed, Feb 26, 2014 at 10:00 AM, Bob Arning <arning315 at comcast.net 
> <mailto:arning315 at comcast.net>> wrote:
>
>     Umm, my reply was to Jon Paynter's message which was basically how
>     to clean up during development. Whether someone finds some
>     applicability to post-development scenarios, well, YMMV.
>
>     Cheers,
>     Bob
>
>
>     On 2/26/14 12:48 PM, Philippe Marschall wrote:
>>     On Tue, Feb 25, 2014 at 7:19 PM, Bob Arning<arning315 at comcast.net>  <mailto:arning315 at comcast.net>  wrote:
>>>     I wonder if this doesn't point the way...
>>>
>>>     expire
>>>          self
>>>              greaseDeprecatedApi: 'WASession>>#expire'
>>>              details: 'This method might be reimplemented again. In the meantime,
>>>     if you just want to remove the Session from the Application, use
>>>     WASession>>unregister (#unregistered will be called as a notification
>>>     instead of #expired). Otherwise you should consider adding a Request Filter
>>>     to the Session that implements whatever behaviour you want in order to block
>>>     access to the Session.'.
>>>          ^ self unregister
>>>
>>>     as well as...
>>>
>>>     WACache allInstances do: [ :e | e reap].
>>     What problem exactly are you trying to solve? Do you have to do some
>>     work when the session expires?
>>
>>     It is true that per default we only expire on every n-th session
>>     creation. You can change this by swapping the reapingStrategy
>>     WAAccessIntervalReapingStrategy. However keep in mind that:
>>       - if somebody just creates sessions but never accesses them you may
>>     still want to reap at some point
>>       - reaping does not scale well, you have to walk over all the sessions
>>
>>     We are aware that the current situation is suboptimal and are working
>>     on a replacement [1] but that may take a moment.
>>
>>       [1]http://lists.squeakfoundation.org/pipermail/seaside-dev/2014-February/005710.html
>>
>>     Cheers
>>     Philippe
>>     _______________________________________________
>>     seaside mailing list
>>     seaside at lists.squeakfoundation.org  <mailto:seaside at lists.squeakfoundation.org>
>>     http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>
>
>     _______________________________________________
>     seaside mailing list
>     seaside at lists.squeakfoundation.org
>     <mailto:seaside at lists.squeakfoundation.org>
>     http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
>
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20140226/7516d807/attachment.htm