Highly available webapps with Java and Spring – Part 2

Leider ist der Eintrag nur auf Amerikanisches Englisch verfügbar. Der Inhalt wird unten in einer verfügbaren Sprache angezeigt. Klicken Sie auf den Link, um die aktuelle Sprache zu ändern.

In part 1 we described a general architecture approach for highly available applications.

Now we’ll go through some technical challenges and our project cat-boot-cluster.

Technological challenges

Since we use the Spring framework a lot, we can benefit from its great integration for using Redis to store session data which was introduced with the relatively recent spring-session project.
As always, there is no free lunch. Just because these frameworks and tools exist doesn’t mean that everything works on its own without any further thought required by us.
One thing that we recently had to deal with is upgrading certain libraries in the context of such a clustered application.

Thanks to our consistent local test environments where we could immediately see the problem before it got anywhere near any production stage. The manifestation of the problem was that as soon as the upgraded version was deployed, any previously logged in users were not able to use the application any longer, they were immediately presented with an error-page. The reason was quickly found: incompatible serialization format between the old and the new version.

Because we only wanted to solve this problem once, we took the time to write our own automatic configuration on top of spring-session which takes care of handling this scenario for any future spring-boot application we need to write.


Check out our cat-boot-cluster project, which enables you to use this yourself by simply adding a dependency to your spring-boot application.

With cat-boot-cluster we even take it a step further and configure things like metric collection and aggregation of these metrics so that you can easily get a holistic view of your clustered application on any one node.

The nitty gritty details

To illustrate the initial session-deserialization problem, we still want to take a short deep-dive into some example code of what is necessary to handle the incompatible session object problem with spring-session:

 * Wrapper session-repository that deletes session objects which can no longer be deserialized
 * adapted from: https://github.com/spring-projects/spring-session/issues/280
 * @author Paul Klingelhuber
public class InvalidClassExceptionSafeRepository<S extends ExpiringSession>
    implements SessionRepository<S> {
  static final String BOUNDED_HASH_KEY_PREFIX = "spring:session:sessions:";

  private SessionRepository<S> repository;
  private RedisTemplate<String, ExpiringSession> sessionTemplate;

  public InvalidClassExceptionSafeRepository(
      SessionRepository<S> repository,
      RedisTemplate<String, ExpiringSession> sessionTemplate) {
    this.repository = repository;
    this.sessionTemplate = sessionTemplate;

  public S getSession(String id) {
    try {
      return repository.getSession(id);
    } catch(SerializationException e) {
      return null;

  public S createSession() {
    return repository.createSession();

  public void save(S session) {

  public void delete(String id) {

When you do this yourself you then have to make sure that an instance of this class is used as the session repository and you are good to go.

Cat-boot-cluster takes care of this for you and the actual implementation there has of course logging and metric collection so that we can see the effects of the code even when it went to production.

Summing it up

Writing highly available applications may seem like an easy task at first sight, but everyone who tells you this probably hasn’t actually done it yet to any meaningful extent.
In this post we presented one issue in particular which you can run into in clustered applications and its solution.
However there are many other things to consider which we haven’t even mentioned yet such as migration issues or task coordination to mention just a few.

Vorheriger Beitrag
Highly available webapps with Java and Spring – Part 1
Nächster Beitrag
CatPhone statt Telefon

Related Posts

Highly available webapps with Java and Spring – Part 1

High availability and fault tolerance are frequently important requirements for customers. By thinking ahead and using the right technologies we at Catalysts can fulfill these requirements to boost your products performance and ensure productivity.


JPF Part 1 – A lightweight alternative to OSGi?

When developing web applications it has always been a challenge how to plug in customer specific extensions and integrations without invading the inner guts of the web application too much. This not only concerns the source code, it is quite easy to keep customer specific sources out of the application’s trunk, the main problems usually arise when thinking about deployment strategies


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Bitte füllen Sie dieses Feld aus
Bitte füllen Sie dieses Feld aus
Bitte gib eine gültige E-Mail-Adresse ein.
Sie müssen den Bedingungen zustimmen, um fortzufahren