[Seaside-dev] Seaside 3.1 and beyond

Diego Lont diego.lont at delware.nl
Wed Feb 5 12:53:03 UTC 2014


Hi,

That sounds great.

Me personally, I agree on your proposal doing it in a 3.2 version. Mainly because it won't work on Gemstone (yet?), and currently release 3.1 has mainly loose ends on Gemstone. But from what I read: great work!

Diego

On Feb 4, 2014, at 9:18 PM, Philippe Marschall wrote:

> 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
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev



More information about the seaside-dev mailing list