Ask Reuben

GAS Session

What is a GAS session ?

What is the Session Id ?

The term “Session” is used many times in the GAS documentation but nowhere does the documentation explicitly state what a session is.  It is referred to in many places such as definition of uaproxy, configuration elements SESSION_COOKIE, SESSION_DIRECTORY, and how to get a Session Id .

The best way to understand is to look at the Architecture diagram …



… when a web application is started, a VMProxy (uaproxy) and DVM (fglrun) is started.  Any Genero applications launched via RUN from that initial program are considered to be part of the same session.  They will be managed by the same proxy.   The proxy and the two DVM in the above diagram enclosed in the red rectangle, that is a session.   The session remains alive until the last fglrun process included in the session terminates, taking the uaproxy process with it.  If you launch a program via launchUrl front-call that will be considered a new session and have its own new proxy process.

The concept of session arises in a number of places.

The most obvious is the name of GAS log files.  For web applications the names of the log files are uaproxy-sessionid.log and vm-sessionid.log where sessionid is the unique identifier for a session (the session id) which is the 32 character long name made up of hexadecimal (0-9a-f) characters. e.g. “”51568e839b386af02bfefcae7c5300f9”.  When you are analysing log files, you will typically do a grep on a dispatcher log file using the session id to find the times of when HTTP requests and responses occurred for that session.

As well as the name of the log files, you will see this session id as the value of the X-FourJs-id cookie and used in the HTTP communication,  In the dispatcher and proxy log files you will see entries such a POST /ua/sua/sessionid.  

The GAS monitor page also displays this session id.



If inside a running program you want to know the name of the session id, you can use FGL_GETENV(“FGL_VMPROXY_SESSION_ID”) to retrieve the session id value (or in the case of web services, retrieve a header, see here for details).  You can use that to populate whowhatwhen tables or an equivalent audit mechanism so that when a user reports they had a problem in a certain program at a certain time, you can easily find the appropriate proxy and vm log file.

The ability for the GAS to automatically end programs after a program of activity,  AUTO_LOGOUT. is controlled by inactivity in a session, not by inactivity in a single Genero application.  As per the AUTO_LOGOUT documentation…

When an application has launched child applications, the auto logout is not triggered while any of its child applications have user activity

… it is the uaproxy process that is keeping track of time and user activity and not the fglrun process.  It is the uaproxy process that says I have not had any user activity from any of the programs that I am looking after, therefore I will instruct all of these Genero programs in my session to exit.

The architecture of GAS has built-in stability in that if a dispatch process fails for any reason, when the dispatcher restarts it can reestablish connections with any sessions that were running when the dispatcher failed.  Hence you see GAS configuration such as the SESSION_DIRECTORY.  It is important that when you have multiple dispatchers running on the same server that the configuration ensures that each dispatcher has its own session directory.  if you don’t you will encounter errors when a dispatcher tries to communicate with sessions owned by a different dispatcher, especially when a dispatcher restarts and establishes communication with its sessions.

You will also come across the word Session in Load Balancing.   There is Sessionless request processing and Session-bound request processing.  With Genero Web applications it is important to use Session-bound load balancing so that each request is managed by the same load balance server and hence the same GAS and fglrun process.  For Genero Web Service applications it is not so important to use the same GAS unless you use Sticky Web Services .

So in summary, I find the best way to think of a session is for a Genero Web Application, each time you type a URL into a browser or click on a link, or execute a launchUrl front-call, this starts a new session.  The session has a “Session Id” to unique identify it that you can see in the HTTP traffic and the name of the log file.  Each child program launched by RUN ‘fglrun …” will be considered to be part of the same session.