On 3 May 2016 at 00:44, Marvin Addison <[email protected]> wrote:
> Is there a bug tracker issue or design document that provides further > information? I'm curious what you're changing and why. > Documentation is soon to be written. Jan will probably comment more as she did the rework, but some of the reason and changes include: - The sessions code base was extremely old and written with an older style approach to synchronization. The code is probably over synchronized and that was not good for modern multi core machines. - Some locks were held during listener invocation, so that there was always the possibility of deadlock if listeners started doing complex things. - As we added new session store types (eg google gcloud) there was a lot of cut and pasting of code required because abstractions were not entirely correct. - The need for a matched session ID manager was both confusing and inflexible. The new session ID manager is now common for all store types and can be left as default in almost all circumstances - All the session managers had been written with mostly sticky load balancing in mind. The new architecture will support jcache/memecache in a way that better supports non sticky clusters - A lot more rigour has been applied to determine when and what passivation means - ie when should listeners be called. This used to be a little different for each store type, but is now common behaviour. In short the SessionHandler now has a SessionCache, which hold a possibly partial collection of activated session objects and zero or more SessionStores that hold a complete store of passivated session data. cheers -- Greg Wilkins <[email protected]> CTO http://webtide.com
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
