After fooling around with other methods, we finally accepted the advice I got on the Wicket IRC channel and used Terracotta to cluster our Wicket-based apps running under Jetty. It turned out to be straightforward to implement.
The first thing to do was to add the Terracotta dependencies to our pom.xml.
<dependency> <groupId>org.terracotta.session</groupId> <artifactId>terracotta-session</artifactId> <version>1.1.1</version> </dependency> <dependency> <groupId>org.terracotta</groupId> <artifactId>terracotta-toolkit-1.1-runtime</artifactId> <version>2.0.0</version> </dependency>
Then you just need to add a Terracotta filter to the jetty WebAppContext as follows:
FilterHolder tcFilterHolder = new FilterHolder(TerracottaJetty61xSessionFilter.class); tcFilterHolder.setInitParameter("tcConfigUrl", "terracotta:9510,terracotta2:9510"); context.addFilter(tcFilterHolder, "/*", Handler.ALL);
That’s it. Terracotta will cluster the session (in the example we’re using two terracotta servers called “terracotta” and “terracotta2” – a main server and a standby).
We’re using a HAProxy load-balancer with session affinity to load-balance and failover the wicket apps. Note that we are only clustering the session and not the Wicket PageMapStore. This means that if the app fails over, the browser back-button will not work correctly after a failover. Since failover should only occur rarely, if ever, we don’t see the need to cluster the PageMapStore (although this is not hard either) and incur the network cost of replicating the PageMapStore.