[Seaside] Re: Session expiration and data cleaning

[Jon Paynter]

that looks promising - where do get PointerFinder?  its not in my
VisualWorks image.


On Wed, Feb 26, 2014 at 11:34 AM, Bob Arning <arning315 at comcast.net> wrote:

>  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>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> <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 listseaside at lists.squeakfoundation.orghttp://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
>>
>>
>
>
> _______________________________________________
> seaside mailing listseaside at lists.squeakfoundation.orghttp://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/9036cad9/attachment-0001.htm