Skip to main content
Version: 4.6.x.x LTS

MultiLevelSessionStoreServlet

Experimental

The MultiLevelSessionsStoreServlet is experimental. It is recommended not using it in production environments. Backwards compatibility with following releases is not guaranteed, and the naming and functionality can change.

The MultiLevelSessionStoreServlet allows sharing user sessions between several nevisProxy instances with low overhead in the normal operation mode.

The MultiLevelSessionStoreServlet is responsible for storing session information in both a local and a backup store, within the context of the Dynamic Session Engine.

This hybrid configuration is meant to be used with several nevisProxy instances and a load balancer. It allows each proxy instance to retrieve the sessions created by another instance in case of a failover scenario. To this end, the MultiLevelSessionStoreServlet combines a LocalSessionStoreServlet with a MySQLSessionStoreServlet.

This is how it works: Each instance stores its sessions locally for optimum performance in the normal operation mode. The sessions are backed up in a common remote session store. When a proxy instance receives a request containing a session identifier, it first looks for the session in its local session store (LocalSessionStore). If the proxy cannot find the session locally, it looks for the session in the backup session store. If the session exists in the backup session store, the proxy copies it to its local session store, otherwise a new session is created.

Limitations

The following conditions must be fulfilled for the MultiLevelSessionStoreServlet to work correctly:

  • The sessions must be handled by the SessionManagementFilter of the Dynamic Session Engine.
  • The load balancer must be session-sticky.
  • In case of a failover from proxy A to proxy B, the load balancer must continue routing existing clients to proxy B after proxy A is back online.
  • The same limitations that are valid for the MySQLSessionStoreServlet apply here as well.
Classname:
ch::nevis::nevisproxy::servlet::cache::multilevel::MultiLevelSessionStoreServlet

Library:
libMultiLevelSessionStoreServlets.so.1

Configuration

MainServlet

Type: string Usage Constraints: required

Sets the name of the LocalSessionStoreServlet used to store the sessions locally. The configuration must contain such a LocalSessionStoreServlet.

BackupServlet

Type: string Usage Constraints: required

Sets the name of the MySQLSessionStoreServlet used to store the sessions remotely. The configuration must contain such a MySQLSessionStoreServlet.

BackupThreads

Type: integer Usage Constraints: optional Default: 10, minimal value: 1

Sets the number of threads performing the backup from the local to the remote session store.

BackupThreads.DelayThreshold

Type: integer Usage Constraints: optional Default: 60

Sets a delay threshold in seconds. If the remote backup storage of the sessions is in delay compared to the local storage for more than the configured value, the system will log a NOTICE. The remote backup storage is set with the BackupServlet parameter, the local storage with the MainServlet parameter.

BackupThreads.QueueLengthThreshold

Type: integer Usage Constraints: optional Default: 100

Sets a queue length threshold, in number of sessions. If more sessions than the configured number are waiting to be backed up to the remote backup storage, the system will log a NOTICE. The remote backup storage is set with the BackupServlet parameter.

RemoteServlet

Type: string Usage Constraints: optional, advanced

The RemoteServlet parameter is only used for very special setups with exactly 2 nevisProxy instances (an active and an inactive nevisProxy line). Never configure it manually, only via nevisAdmin4, to avoid any security issue. The relevant nevisAdmin4 property name is Session Store Peer Address.

KeepDeletedEntriesTimeout

Type: integer Usage Constraints: optional Default: 0, max. value: 3600

If a session is removed from the local cache it may take a while until the entry is deleted from the BackupTable as well. Usually the delay is some milliseconds but if the database has some issues this may take several seconds. In order to avoid that a session is reused (because it will be found in the BackupTable), with this parameter the entry will be marked as 'deleted' for the configured number of seconds.

Sample configuration

Refer to the chapter: Setting up the MultiLevelSessionStoreServlet, for an example configuration.