Introduction

Let’s start with the session handling basics. When a 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 that 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. Session data, such as the user ID, is not saved to the server or any other storage, but instead within the browser’s cookie. There is a limitation on the amount of data a cookie can store. It’s also easy to make this insecure unless done correctly: the cookie needs to be encrypted in a way that can’t be decrypted, even if the cookie is hijacked by a malicious user. Certainly, hybris doesn’t use this approach.
• Sticky sessions. They mean that 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” are a common way to solve the problem described at the beginning. If the session storage is not shared and the server goes down, the user will lose all the session data. To overcome this, there are two strategies.
  • Replicating the session data across the cluster. The load balancer redirects requests from the failed server to another server, and that server will use its copy of the session to continue the client’s session from where it was before the failure. Thus, the client will not notice any service interruption, which is the goal of a high-availability strategy. Read more on why clustering and session replication are needed here.
  • Central shared session storage. Persistent stores such as an RDBMS or NoSQL databases are commonly used as session drivers. RDBMSs, such as MySQL or Oracle, are considered too slow for session handling because every request may update or insert data. NoSQL databases are much better for this purpose: Redis, MongoDB, Tarantool, Memcached, and Cassandra.
• Non-sticky sessions. Non-sticky session replication provides higher performance, while the sticky-session approach provides higher reliability. For non-sticky sessions, replication should work much faster because every single request may be processed by any server in the cluster. Centralized storage is a good option for non-sticky sessions.

As we can see, centralized session storage looks like the universal solution for both sticky and non-sticky sessions. The default hybris does not support centralized session storage, and 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