Seaside 3.1 and beyond

> Hi
>
> During FOSDEM I made some great progress on the replacement of the
> session cache (see below for a better description). I believe it is
> mature enough to be rolled into the framework (famous last words). So
> the question becomes when and how. Any combination of 3.1/3.2 and
> now/later is possible. Doing it in 3.2 has the advantage that we can
> keep 3.1 stable and just do maintenance there. The downside is that
> maintenance is more effort because most things would likely have to be
> done on both branches. Doing it in 3.1 would reduce that maintenance
> effort at the expense of destabilizing the 3.1 branch (at least
> temporarily). Doing it in 3.2 would additionally have the benefit that
> we could do even more optimizations like removing the need for
> #keyAtValue:. Doing 3.2 early would give us the chance of stabilizing
> it earlier but taking resources away from maintaining 3.1.
> Considering these factors my proposal is doing it in a 3.2 somewhere
> around ESUG.
>
> Now some words on the cache itself. The current session cache has
> several limitations:
> * it does not scale well [1]
> * it does not support absolute session timeouts
> * it does not support limiting the number of active sessions
> I have been working on a new session cache that addresses these issues
> [2]. The performance of the current cache can get quite bad. To give
> you an example just storing 10000 elements takes 10 seconds on my
> machine. The new implementation without much tuning and more features
> uses about 50 ms. The current cache doesn't have have a way to just
> scan the oldest sessions, it has to scan all the sessions. As a
> consequence this is more effort the more sessions you have. Per
> default the current cache clears old sessions after 10 sessions have
> been created thereby slowing down session creation. It could be
> changed to clear old sessions after a certain number of sessions have
> been accessed but that would slow down access. In addition if you only
> create sessions but never access them you have a leak.
> The proposed implementation arranges sessions so that the oldest can
> be accessed easily. This eliminates the need to touch any active
> sessions. It can therefore clear all the old session on every
> retrieval and store and still be faster (access is a little faster,
> store is a lot faster).
> While the current cache offers extension points (plugins) they can't
> change the storage. As a consequence we currently only support
> relative session timeouts and not absolute session timeouts. OWSAP
> recommends having both absolute and relative session timeouts [3].
> And finally the current cache doesn't allow setting a maximum size.
> It's not possible to have any kind of QoS eg. under load reject new
> sessions but keep serving existing sessions. The proposed
> implementation has an optional maximum size with a configurable
> overflow action (signal an exception, expire the oldest one, expire
> the one not accessed for the longest time).
>
> One limitation of the proposed implementation shared with the current
> one is that it's not possible to bump the session lifetime for a
> single session (sorry Boris). Also it won't work on GemStone.
>
> [1] http://code.google.com/p/seaside/issues/detail?id=262
> [2] http://ss3.gemstone.com/ss/SeasideCacheNG
> [3] https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Automatic_Session_Expiration
>
> Cheers
> Philippe
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

> Hi
>
> During FOSDEM I made some great progress on the replacement of the
> session cache (see below for a better description). I believe it is
> mature enough to be rolled into the framework (famous last words). So
> the question becomes when and how. Any combination of 3.1/3.2 and
> now/later is possible. Doing it in 3.2 has the advantage that we can
> keep 3.1 stable and just do maintenance there. The downside is that
> maintenance is more effort because most things would likely have to be
> done on both branches. Doing it in 3.1 would reduce that maintenance
> effort at the expense of destabilizing the 3.1 branch (at least
> temporarily). Doing it in 3.2 would additionally have the benefit that
> we could do even more optimizations like removing the need for
> #keyAtValue:. Doing 3.2 early would give us the chance of stabilizing
> it earlier but taking resources away from maintaining 3.1.
> Considering these factors my proposal is doing it in a 3.2 somewhere
> around ESUG.
>
> Now some words on the cache itself. The current session cache has
> several limitations:
> * it does not scale well [1]
> * it does not support absolute session timeouts
> * it does not support limiting the number of active sessions
> I have been working on a new session cache that addresses these issues
> [2]. The performance of the current cache can get quite bad. To give
> you an example just storing 10000 elements takes 10 seconds on my
> machine. The new implementation without much tuning and more features
> uses about 50 ms. The current cache doesn't have have a way to just
> scan the oldest sessions, it has to scan all the sessions. As a
> consequence this is more effort the more sessions you have. Per
> default the current cache clears old sessions after 10 sessions have
> been created thereby slowing down session creation. It could be
> changed to clear old sessions after a certain number of sessions have
> been accessed but that would slow down access. In addition if you only
> create sessions but never access them you have a leak.
> The proposed implementation arranges sessions so that the oldest can
> be accessed easily. This eliminates the need to touch any active
> sessions. It can therefore clear all the old session on every
> retrieval and store and still be faster (access is a little faster,
> store is a lot faster).
> While the current cache offers extension points (plugins) they can't
> change the storage. As a consequence we currently only support
> relative session timeouts and not absolute session timeouts. OWSAP
> recommends having both absolute and relative session timeouts [3].
> And finally the current cache doesn't allow setting a maximum size.
> It's not possible to have any kind of QoS eg. under load reject new
> sessions but keep serving existing sessions. The proposed
> implementation has an optional maximum size with a configurable
> overflow action (signal an exception, expire the oldest one, expire
> the one not accessed for the longest time).
>
> One limitation of the proposed implementation shared with the current
> one is that it's not possible to bump the session lifetime for a
> single session (sorry Boris). Also it won't work on GemStone.
>
> [1] http://code.google.com/p/seaside/issues/detail?id=262
> [2] http://ss3.gemstone.com/ss/SeasideCacheNG
> [3] https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Automatic_Session_Expiration
>
> Cheers
> Philippe
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

> On Wed, Feb 5, 2014 at 9:00 PM, Johan Brichau <[hidden email]> wrote:
>> Hi Philippe,
>>
>> Sounds very interesting. Great work as usual!
>> It's a good idea to keep it for 3.2 and settle that around ESUG.
>>
>> I'm also interested to know if there is a fundamental problem to port it to Gemstone?
>
> The same reason the current cache doesn't work as well: multiple
> transactions modifying the same data structure will give you a lot of
> conflicts. I don't know enough about rc-collections to come up with a
> design that would work well on Gemston. OTOH if we manage to get rid
> of the need for #keyAtValue:ifAbsent: at least the Gemstone specific
> cache should become simple.
>
> Cheers
> Philippe
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev