Session Persistence

When Web Servers are configured for Load Balancing, they are often configured by someone not familiar with the Genero architecture.  With a typical load balanced web server architecture servicing atypical web applications and web services,  any server could be selected to handle the next request.  With a Genero Web Application, the fglrun process remains alive for the duration of the web application holding data in memory and connections to database cursors, etc.  and it is important that all requests associated with an individual web application are sent back to the same server where this fglrun process is waiting.

In our GAS documentation, the concept of sending requests back to the same server is called session-bound request processing.  This is required for Genero Web Applications and also for Genero Web Services that have been configured to be sticky.  For normal Genero Web Services, a more traditional web architecture can be used with sessionless request processing where it does not matter what server processes each individual request.

In our documentation, we show how to configure both Apache and IIS Web Servers for both session-bound and sessionless request processing.  Typically the difference in the configuration is very small, an extra attribute and maybe a few extra lines.

If you are using other web servers, you will need to look for words like session-bound or the other common term used is “session persistence” in their documentation.  The NGINX documentation on Load Balancing has a very good section on Session Persistence. including a critical point that NGINX Plus handles session persistence, NGINX does not.    The Wikipedia page on Load Balancing also has a section on persistence.

If you are interested in how the session bound / persistence concept works, the session-bound request processsing explains it very well.  One technique involves a cookie being attached to the request and response, and the load balancer reading the value of this cookie in order to determine what server to process the request.  Another technique involves information about the server being incorporated within the URL and the load balancer reading the URL to determine what server to process the request.

If you do misconfigure a web application under load balancing, the logs will give you clues.  On the server where the original request was made you will see the uaproxy and and vm log indicating that the fglrun process timed out waiting for the next request that never arrived.  On the server where the second request was sent, you see the dispatcher log indicating that there was no uaproxy to communicate with.

The concept of session persistence also has implications when it comes to shutting down a server as demand falls.  You have to wait for the fglrun processes on that server to finish, at the moment you can’t move that fglrun process from one server to another.

The requirement for session persistence is not unique to Genero web applications however it would be fair to say that it is in the minority.