Wicket UI in the cluster - reflection
10 May 2019
In the last blog post I've talked about the technicallies of running Wicket clustered.
But there are more things to consider.
The session handling of server based web applications is usually done by the web application server which in the Java world runs on top of a Servlet container.
The Servlet specification contains the session and cookie handling.
In a cluster environment it is also the responsibility of the application server to create an environment where it replicates the session.
As outlined in the previous article it is possible to follow certain best practices to help Wicket keep the session small, like using LoadableDetachableModel's.
But the application server relies on a certain level of reliability of session stickiness of the load-balancer.
There usually are a few scenarios how the session replication can work.
If the session is stored in a database that all cluster nodes can use at the same time it might be possible that the application works without LB session stickiness.
It is also possible to store the session in memory using a technology like Hazelcast, Apache Ignite or something like that.
So it is highly recommended to use the application servers second-level cache for performance reasons and use session stickiness of the load-balancer.
For more info take a look here: https://ci.apache.org/projects/wicket/guide/8.x/single.html#_lost_in_redirection_with_apache_wicket