Non-sticky Session Load Balancing

Non-sticky session configuration means that you do not route all the requests to the same server that handled the initial request. Subsequent requests can be routed to any of the servers in the pool for processing. Again, we recommend you use a sticky session load balancing environment with Logi Info because certain files need to be shared across servers, which can be slower in a network environment.

If you must use a non-sticky session configuration, you will face these challenges:

Session replication can be contentious
File access performance can impact app performance and in some cases can cause race-conditions, leading to errors
Performance impact on distributed file systems, e.g. EFS, would be greater, especially for high file I/O requirements for rdDatacache folder
Hosting on cloud (AWS, Azure, GCP, etc.) adds additional complexity to the above issues

To deploy a non-sticky environment, follow these steps:

Configure Load Balancer to be set to non-sticky
Prepare environment for centralization of resources (see Application Resource Centralization)
Centralize rdDataCache (see below)
Configure Logi Info application
Deploy application to all web servers

Centralizing rdDataCache for Non-Sticky Sessions Only

The data cache repository is, by default, the rdDataCache folder in a Logi application's root folder. In a standalone environment, where all the requests are processed by the same server, this default cache configuration is sufficient.

In a non-sticky load-balanced environment, centralizing the data cache repository is required. This will pose additional challenges to customers who want to use a non-sticky load balanced environment. If you do insist on using this configuration, make sure you centralize the data cache in this way.

This is accomplished in Studio by editing a Logi application's _Settings definition, as shown above. You need to set the General element's Data Cache Location attribute value to the UNC path of a shared network location accessible by all web servers. You need to make this change in the _Settings definition for each instance of the Logi application (i.e. on each web server). When you specify a network folder for the data cache, you need to change the identity that the web server uses to run the application (usually ASPNET or NETWORK SERVICE or the Application Pool), or impersonates, to a network domain account that has Full Control access permissions for the specified folder.

This attribute will support relative path notation, such as two periods ".." used to indicate a parent folder. For example,

@Function.AppPhysicalPath~\..\..\..\..\OurDataCache

Managing Session State for Non-Sticky Sessions

A "session" is defined as the period of time in which a unique user interacts with a particular web application. HTTP is a "stateless" protocol, in the sense that a web server is concerned only with the current HTTP request for any given web page. The web server retains no knowledge of previous requests and the stateless nature of HTTP requests presents unique challenges when writing web applications. In clustered environments, where non-sticky sessions are desired, session state needs to be replicated to all members of the cluster.

State Replication for ASP.NET and IIS for Non-Sticky Session Environments

Your ASP.NET applications require the session state to be maintained using one of these three session management options:

InProc - Session state is stored locally on the web server and is managed in the same worker process as the ASP.NET application.
StateServer - Session state is managed by the ASP.NET state service, which runs outside of the ASP.NET worker process. The service can run on a different server to support web farms.
SQLServer - Session state is managed outside of the ASP.NET worker process and is stored in a SQL Server database. Like the StateServer option, this method can support web farms.

Additional considerations, other than load balancing, may affect the choice of session state management options. IIS is configured by default to manage session information using the "InProc" option. For both standalone and load-balanced, sticky environments, this option allows a single server to manage the session information for the life of the session. For non-sticky, load-balanced configurations, session state needs to be managed centrally. Since requests can be processed by any of the available servers, the servers need to be able to access session information from a common location. Therefore, you should use either the StateServer or SQLServer management options in this circumstance. Use your IIS Management Tool, in the ASP.NET configuration tab or dialog box, to actually configure your session management options; however, the details are beyond the scope of this document. Refer to your IIS documentation.

State Replication for Java and Apache Tomcat for Non-Sticky Session Environments

Use this link for detailed instructions about creating clustered implementations of Apache Tomcat. This procedure describes how you configure Tomcat for in-memory (multicast) and database (persistent) session replication across all members of a cluster (some of the information presented here is drawn from the clustering instructions at the link above). To configure in-memory session replication:

Modify your server.xml file by adding the following in either the <Engine> or <Host> sections:

To configure use of a database for session replication, follow these steps:

Ensure that the <Cluster> element is disabled in your server.xml file to turn off in-memory replication.
Navigate to the root of your Logi app and, if it doesn't already exist, create a folder named META-INF.
In the META-INF folder create a file named context.xml and open it in a file editor.
In the file, define a root <Context> element, and then add the following <Manager> element to that section:

Determine what type of database you want to use for session persistence and copy the .JAR driver file for that database into the Tomcat lib folder.
Add the following <Store> element within the <Manager> section:

<Store className="org.apache.catalina.session.JDBCStore"
   connectionURL="jdbc:<your_jdbc_connection_url>"
   driverName="<your_jdbc_driver_classname>"
   sessionIdCol="session_id"
   sessionValidCol="valid_session"
   sessionMaxInactiveCol="max_inactive"
   sessionLastAccessedCol="last_active"
   sessionTable="tomcat_sessions"
   sessionAppCol="app_context"
   sessionDataCol="session_data"
/>

Execute the following SQL command against the database specified in your JDBC connection URL:

create table tomcat_sessions (
   session_id varchar(100) not null primary key,
   valid_session char(1) not null,
   max_inactive int not null,
   last_access bigint not null,
   app_context varchar(255),
   session_data mediumblob,
   KEY kapp_context (app_context)
);

Configure Logi Info Application

Regardless of which replication method you chose above, complete the session configuration with these steps:

In <LogiAppFolder>/WEB_INF/web.xml, ensure that the <distributable/> tag is included.

In <LogiAppFolder>/WEB_INF/web.xml, set the EnableSessionPersistency context parameter to True. This parameter is present in all Logi apps by default.

Here's a partial file example, with both additions highlighted:.

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
       "http://java.sun.com/dtd/web-app_2_3.dtd"[]>
    <web-app id="WebApp_ID">
    <display-name>Logi Server for Java 12.2.225-SP5</display-name>
    <description>Logi Server for Java 12.2.225-SP5</description>
    <distributable/>
    <context-param>
    <param-name>EnableSessionPersistency</param-name>
     <param-value>True</param-value>
    </context-param>
       ...

In your Logi application's _Settings definition, add a Java Session Copying element:

Copy to Java Include