Local session store configuration example

If a session is needed, it is the SessionManagementFilter that creates as well as handles the session and defines the method of session binding (for example with cookies). The session store servlets, such as the LocalSessionStoreServlet, are responsible for storing and loading the session data.

To set up a cookie-based SessionManagementFilter using a local session store, you have to configure the web.xml file as shown in the sample code below:

<filter>
        <filter-name>CookieBasedSessionManagementFilter</filter-name>
        <filter-class>ch::nevis::nevisproxy::filter::session::SessionManagementFilter</filter-class>
        <init-param>
                 <param-name>Servlet</param-name>
                 <param-value>LocalSessionStoreServlet</param-value>
        </init-param>
        <init-param>
                 <param-name>Identification</param-name>
                 <param-value>Cookie</param-value>
        </init-param>
        <init-param>
                 <param-name>Cookie.HttpOnly</param-name>
                 <param-value>true</param-value>
        </init-param>
        <init-param>
                 <param-name>Cookie.Name</param-name>
                 <param-value>NPSession</param-value>
        </init-param>
</filter>
 
<! - add here other filters -->
     
    <filter-mapping>
        <filter-name>CookieBasedSessionManagementFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
 
<!-- add here other filter-mappings -->
 
<servlet>
    <servlet-name>LocalSessionStoreServlet</servlet-name>
    <servlet-class>ch::nevis::nevisproxy::servlet::cache::local::LocalSessionStoreServlet</servlet-class>
    <init-param>
        <param-name>MemorySize</param-name>
        <param-value>1073741824</param-value>
    </init-param>
    <init-param>
        <param-name>MaxInactiveInterval</param-name>
        <param-value>120</param-value>
    </init-param>
    <init-param>
        <param-name>MaxLifetime</param-name>
        <param-value>86400</param-value>
    </init-param>
</servlet>
 
<!-- add here other servlets followed by the servlet-mappings -->

MemorySize considerations

The MemorySize parameter of the LocalSessionStoreServlet defines the number of bytes available in the store for local session storage. To calculate an appropriate store size, a lot of factors come into play, such as the available memory on the server, the nevisProxy configuration, the expected load on the nevisProxy instance, and so on. To ease the process of finding a proper session store size, you can calculate the average size of an individual nevisProxy session, and scale this up to the expected load, with some additional buffer.

Option 1

The trace group NPReaperOP can be used to log session store statistics to the Navajo log file on INFO level. In case of a LocalSessionStore, such a statistic looks like this:

2020 11 17 11:10:59.215 5.5.5.5    NPReaperOp 55617.140461721470720 6-INFO  :  LocalCacheTable statistics for LocalSessionStoreServlet: used session: 205, timed out sessions: 0, Used memory: 1085992 (2%), available Memory: 48907472

In this example, we configured 50 MB as memory size for the LocalSessionStoreServlet (set in the parameter MemorySize). With a test load of around 200 sessions, we reached approximately 2% of this size. This means that an average session size in this configuration (basic authenticated sessions) is around 5 KB.

The memory size depends heavily on the exact configuration. For example, what, how many and how big attributes are stored in a session. Therefore, checking the memory size in a test environment is recommended.

Option 2

Another approach is to monitor the logged messages in the Navajo log file.

By default, the LocalSessionStoreServlet will trace a NOTICE level message if the used memory reaches 70%. At 90%, a CRITICAL message (CACH-0067) is logged. No new sessions will be created. As a consequence, some clients may no longer be able to log in. At 95%, an EMERGENCY message (CACH-0068) is logged. No sessions will be created or changed anymore. This means that users will no longer be able to log in, perform a step-up, or similar.

By monitoring these messages, you can make additional configuration changes to increase or decrease the configured memory size of the session store.