About Client Session Management

Prior to OTM 6.3.2, there was only one method of client session management: a simple FIFO (first in-first out) queue. The size of the queue was managed by the glog.webserver.max_sessions property. When a client session was removed from the queue, the data within it was lost forever.

In 6.3.2 this was expanded to include a new method: timeout. The method that is used by OTM is controlled by the glog.webserver.clientSession.method property. By default, the method used is the queue.

In a multiple web server environment, it is imperative that all client session settings are the same across instances otherwise unforeseen irregularities may occur.

The property glog.session.Perf.trackallows you to have all session performance overhead suppressed. Set the property to true to enable. Note that session performance tracking adds overhead to each session call.

Queue

An LRU (least-recently used)  queue manages the client sessions within your session. Each time the client session is accessed it is re-inserted at the end of the queue. When the queue is full, the least recently accessed client session is removed and the new client session is inserted at the end of the queue.

The approach of using an LRU queue instead of the FIFO (first-in first-out) was due to the problems where if a page is left open and is actively being used and a number of other pages with new client sessions are opened the original page's client session is removed which leaves that page in a bad state. The next access of that client session would be expecting data that is no longer available. Prior to the addition of the glog.webserver.showSessionErrorPage property,this would result in exceptions. With this property turned on, you would be redirected to an error page stating that the client session is no longer valid. This change reduces the chances of this happening if you are actively using that client session. A version of this was previously used on advanced layout pages and pages reached by using bread crumbs.

The queue, as in previous releases, is handled synchronously using a list.

Controlling the Size of the Queue

The property glog.webserver.clientSession.maxActive replaces the glog.webserver.clientSession.method property in order to keep all of the client session properties under the same naming structure. The previous property is no longer valid. If the queue is at its limit and no client sessions can be removed, you will receive an error  "TOO_MANY_SUBSESSIONS".

Timeout

Client sessions are handled synchronously using a hash map. The client session is removed from the list once it is idle past its inactive interval or when it is set to be released and is idle past the unused inactive interval.

Maximum Number of Active Client Sessions

The maximum number of client sessions available is defined by the glog.webserver.clientSession.maxActive property. If the number of active client sessions is at the max then you will receive a TOO_MANY_SUBSESSIONS error. A window will need to be closed or you will have to wait until a client session has timed out depending on other property settings.

Inactive Interval

The inactive interval is used to define how long a client session can remain idle before it times out and is removed from the map. It also can be thought of as the client session's timeout value. It is set using the glog.webserver.clientSession.timeout.maxInactiveInterval property. This value cannot exceed the session timeout value defined in the web.xml file. The active time of a client session is reset each time the client session is used or if a page using the client session is part of an active bread crumb trail and the bread crumb trail is updated.

Releasing Unused Client Sessions

By setting the glog.webserver.clientSession.releaseMaxInactiveInterval property, the system can be used to count how many current windows are using the client session. Once the number reaches zero, the client session is marked to be released and it will so when it is inactive for the period of time denoted by the property. The client session can be unmarked if it is accessed before this interval is reached.

Using this feature will create extra network traffic as each page needs to talk to the server when it is loaded and unloaded to update the client session's count.

Setting this property to zero (0) turns off this feature. All client sessions will be retained until they are inactive past their inactive interval if using the timeout method. For the queue method, they will remain in the queue until pushed out.

Scheduling the Timeout and Release Intervals

There are two ways this can be achieved: using a scheduler or having the client session servlet filter on each access check for inactive client sessions. This is controlled by the glog.webserver.clientSession.schedulerThreadCount property. If the value > 0 then the scheduler is used; otherwise, the filter check method is used.

There is no way of knowing which of these two options is the best. You should experiment to determine the optimal configuration.

Scheduler

The scheduler schedules tasks in the future. In this case, the task being scheduled is the removal of the client session from the user's session. The tasks are performed on their own threads. The number of threads available to handle the timeout and release tasks is defined by the glog.webserver.clientSession.schedulerThreadCount property. It must be greater than 0. Modifications to client sessions are handled synchronously. Therefore, when client sessions time out only one can be processed at a time meaning this value should never have to be modified. Adding more threads will allow more commands to run concurrently, however each will still need to wait until the one actively updating the client session list to complete.

Client Session Filter Check

During the preprocessing of the client session filter all of the user's client sessions are checked to see if they have either passed their inactive time or released unused time (dependent upon other property settings). Client sessions would exist longer than these times since they are only checked on each servlet call. This is the slower method of the two but may be necessary dependent on the client's environment.

Multiple Web Servers

In a client environment with multiple web servers, it must be determined how user sessions are handled. The scheduler method will only work if the sessions are sticky. In a failover case where the session is able to be successfully transferred to another web server, this method will still work, but the tasks are rescheduled from scratch. Such cases are not allowed; you currently need to log back in on failovers. If any approach is used which allows user sessions to span or jump web servers then the filter check method must be used.

Pinning Client Sessions

A client session can be set to not time out or be pushed out of the queue. This is called pinning the client session. They will remain as long as your session is active.

Pinning a client session is achieved by adding a glog.webserver.clientSession.pinServlet property entry. This property can be added multiple times. The value of the property is the servlet that you want to pin. Pinning works only for the servlet that creates the client session. For example, servlet A is set to be pinned. Servlet B creates client session 1. The page created by servlet B has a link to servlet A that will reuse client session 1. Launching that link will not pin client session 1.

Pinned client session can be released using the release unused feature.

It is very dangerous to use this feature with the queue method or with the release unused feature disabled. You can run out of available client sessions very quickly with no ability to create new ones.

What Happens if a Window is Closed Before it has Finished Loading

The servlet will still run to completion even if the window is closed early. The client session will still exist during this time. Once the servlet is complete, it will then be set for release.

It is possible to close the window at a point in time where it is loaded, but the page's load and/or before unload events are not yet attached. In these cases the client session could possibly be left hanging out there and the only way to release them is to log out and log back in. It is a timing issue on when this can occur and cannot be duplicated on demand.

Bread Crumb Trail

When a client session is added onto/modified on an existing bread crumb trail, all of the existing client sessions on the same bread crumb trail are reset before the servlet is run and after the servlet is run. For queue management, this means that the client sessions are moved to the end of the queue and for timeout management each client sessions' idle time starts anew.

Error Messages

Error Message	Description
This session has expired. Close all windows and log back into the application.	The user's session is no longer valid.
The client session sweeper does not exist. Close all windows and log back into the application.	The client session sweeper that manages the client sessions does not exist on the user's session. This error should never appear unless something very catastrophic has happened.
This client session has expired. See online help for more information.	The client session does not exist on the user's session. The client session has either timed out, been pushed out the queue, been released, or an invalid client session ID was on the URL.
You have reached the maximum amount of client sessions allowed. See online help for more information.	The user has reached the maximum number of client sessions available to them. This error will appear if using the queue that all of the client sessions are pinned or if using timeouts that the user has reached the maximum number of active client sessions.