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

Reply via email to