Also if you shut down sessions, you need a grace period which lengthens the update time.
2017-07-26 16:05 GMT+03:00 Bas Gooren <[email protected]>: > Hi All, > > TL;DR: How/where do you host your wicket apps so you can deploy a new > version while users are actively using the old/current version? In > particular: when the new version cannot read the sessions of the old > version due to page changes. > > We’re investigating how we can eliminate downtime in some of our apps while > we deploy a new version. > > Most of the stuff we’ve built in the past could handle 30 sec downtime > without much issue (e.g. outside office hours). > > However, we would like to be able to deploy more often; Perhaps even move > towards continuous deployment. > > Currently, using wicket, this seems problematic due to two reasons: > > - Wicket’s sessions (http session and in particular wicket’s filestore) > require affinity > - Session incompatibility: new version of app usually cannot deserialize > old sessions; If we simply take the old version offline, users will > need to > start with a fresh session > > Since we would like to do deploys without service interruption for active > users, I imagine something like session draining on the “old” version after > the “new” version goes online. > Haproxy has support for this: launch new version and route new users to it, > put old one in maintenance mode and take it offline when all sessions for > it have expired (or after predetermined timeout, e.g. 30 minutes). > > Most cloud providers (e.g. heroku, jelastic) don’t handle this gracefully > for as far as I can tell. While they do handle rolling upgrades, they > assume statelessness or otherwise transferable statefulness (new version > can read state of old version). > > Tomcat has support for parallel deployments ([1]), but I’m not a big fan of > running multiple apps in a single JVM. > > Since we don’t build things that will require massive horizontal > scalability, powerful virtual servers have always worked great for us. > > That means we’ll probably need to put a reverse proxy in between our > frontend (apache for SSL termination) and app server (tomcat) to handle > routing. > But of course, before we build something like that on top of haproxy (or > other…) I’d like to make sure we’re not reinventing the wheel. > > I’m curious how other users of wicket handle this: how do you handle active > user sessions (with state) when rolling out a new version of your app? > > I’d be grateful for any insights and experiences from other wicketeers! > > http://tomcat.apache.org/tomcat-8.5-doc/config/context. > html#Parallel_deployment > > > Met vriendelijke groet, > Kind regards, > > Bas Gooren >
