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

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>

  © Rauf Aliev, August 2016