Hybris cluster / Redis session failover

Introduction

Let’s start with the session handling basics. When the user logs in, the session is created on one web server in the cluster. On subsequent requests, the load balancer may bounce that user to another web server which doesn’t have that session information. To the user, it appears that they are no longer logged in.

There are two common fixes for this:

  • Cookie-based sessions.  Cookies are used to store the session information. The session data, such as the user ID, are not saved to the server or any other storage but are instead within the browser’s cookie. There is a limitation of the available amount of data a cookie can store. It’s also easy to make insecure unless done correctly – the cookie needs to be encrypted in a way that can’t be unencrypted, even if the cookie is hijacked by a malicious user. Certainly, Hybris doesn’t use this approach.
  • Sticky sessions. They mean user sessions, usually identified by a cookie, will tell the load balancer to always send requests from a client to the same server. Thus all requests from the same client are sent to the same server. “Sticky sessions” is a common way to solve the problem described at the beginning. If the session storage is not shared, in the case of the server is down, the user will lose all the session data. To overcome it, there are two strategies.
    • Replicating the session data across the cluster. The load balancer redirects requests from the failed server to another server that server will use its copy of the session to continue client’s session from where it was before the failure. Thus the client will not notice any service interruption, which is the goal of high availability strategy.  Read more on why and what for clustering and session replication here.
    • Сentral shared session storage. Persistent stores such as a RDBMS or NoSQL databases are commonly used as session drivers. The RDBMS, such as MySQL or Oracle, are considered too slow for the session handling, because every request may update or insert data. NoSQL databases are much better for this purpose: Redis, MongoDB, Tarantool, Memcached, Cassandra.
  • Non-sticky sessions. Non-sticky session replication provides higher performance, while sticky session approach provides higher reliability. For non-sticky sessions, the replication should work much faster because every single request may be processed by any server in the cluster. The centralized storage is a good option for the non-sticky session.

As we see, the centralized session storage looks like the universal solution, both for sticky and non-sticky sessions. The default hybris doesn’t support the centralized session storage, but the newer versions support it to an even lesser extent.

Solution

redis-1.png

Demo of PoC

Details

JARs (platform\tomcat\lib):

  • tomcat-redis-session-manager-2.0.0.jar
  • commons-pool2-2.2.jar
  • jedis-2.5.2.jar

Configuration :

<Context path="/trainingstorefront" ... >
<Valve className="com.orangefunction.tomcat.redissessions.RedisSessionHandlerValve" />
<Manager className="com.orangefunction.tomcat.redissessions.RedisSessionManager"
 host="127.0.0.1" 
 port="6379" 
 database="0" 
 expireSessionsOnShutdown="false" 
 notifyListenersOnReplication="true"
/>
<Loader ... />
</Context>

 

 

 

4 comments

  1. Igor Sokolov · · Reply

    Hey Rauf, do you know that hybris doesn’t store almost nothing in HTTP session, everything is stored in JaloSession. For instance if you invoke SessionService.setAttribute() then the information will be placed in memory in JaloSession which doesn’t have anything with HTTP session except that the last one has ID of JaloSession. So in this case even if you do reliable HTTP session then it doesn’t solve the issue that JaloSession information will be lost.

    Another point is that instead of replacing Tomcat implementation of Session there is better in my opinion approach specifically use Spring Session which will work in other Servlet Containers/EE servers.

    Like

  2. Igor Sokolov · · Reply

    I was slightly wrong in my first statement. I don’t know when but hybris removed independence between HTTP session and Jalo session and how the last one is just placed into HTTP session as an attribute so if you store HTTP session in Redis then Jalo session should also magically appear in Redis.

    Liked by 1 person

    1. We all know that it is magic 😉 I experimented with 6.0

      Like

  3. Carrie Bennett · · Reply

    We are trying to set this up on hybris 6.0 – our httpsession is being retrieved, however our jalosession appears to be lost. This is the error we are receiving:

    [JaloSession] Jalo session (…) has been created in context of tenant which since that has been initialized/updated – session is not adequate anymore.

    Did you have to do any additional work to get around an error such as this?

    Thanks for any help you can provide, much appreciated

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: