Handling of Abandoned Sessions

When logout and refresh API calls do not reach Sentinel Cloud Connect during a specified interval, for example in the case of browser crash, the license session is treated as abandoned.

This topic explains how abandoned sessions are treated for cloud licensing.

Cloud Licensing

Configurations

A background process uses the following configurations to identify abandoned sessions and remove them:

Configuration Property	Description
License Session Timeout (mins)	This configuration is for all license models, in which vendor's application calls the refresh API frequently. Session timeout (with refresh) and session timeout (without refresh) value is derived from this property. This property helps to identify abandoned sessions. For example, if this value is 1440 minutes, then whenever background process will run, it will check for records where stop time is null and last refresh time is less than (current time – 1440) minutes. These sessions will be treated as abandoned sessions. Concurrency will be freed and sessions will be completed by putting last refresh time into stop time. Use EMS GUI to update the default value of this field located at: Admin Console > Sentinel RMS <Version> Cloud Add-on Enforcement > License Session Timeout. NOTE The background thread is configured to run at an interval of every 30 minutes.
Number of Days to Consider Records (Days)	This configuration is required to search for a given time period, typically from (current time – x) days to improve performance. The value is fixed to 30 days for this property.

Configuration Property

Description

License Session Timeout (mins)

This configuration is for all license models, in which vendor's application calls the refresh API frequently. Session timeout (with refresh) and session timeout (without refresh) value is derived from this property.

This property helps to identify abandoned sessions. For example, if this value is 1440 minutes, then whenever background process will run, it will check for records where stop time is null and last refresh time is less than (current time – 1440) minutes. These sessions will be treated as abandoned sessions. Concurrency will be freed and sessions will be completed by putting last refresh time into stop time.

Use EMS GUI to update the default value of this field located at: Admin Console > Sentinel RMS <Version> Cloud Add-on Enforcement > License Session Timeout.

NOTE The background thread is configured to run at an interval of every 30 minutes.

Number of Days to Consider Records (Days)

This configuration is required to search for a given time period, typically from (current time – x) days to improve performance. The value is fixed to 30 days for this property.

Examples

Consider the following configuration values:

>Background Process Periodic Interval : 30 minutes

>License Session Timeout (with Refresh): 1440 minutes

In this case, the license session would be cleaned up in approximately 1440 + 30 minutes.

Guidelines on Setting Configurations

Given below are some guidelines on setting configurations related to the background process:

License Session Timeout (in mins): 1440 minutes (1 Day) [Default].

This value his set depending upon the following considerations:

>How frequently a vendor calls the refresh API?

The vendor has to call refresh API periodically so that if the refresh is successful, then only the vendor's application allows the user to continue. The vendor needs to identify this periodic interval.

>How many missed API calls or the maximum time is permitted between two refresh session calls?

There might be cases that vendor's application calls refresh API but due to network error, it could not reach the Sentinel Cloud Connect. The vendor needs to decide if the missed refresh calls need to be considered or not. The advantage is if even one or two calls do not reach the Sentinel Cloud Connect, the background process will not clear these sessions. But, the disadvantage is if user’s session is killed due to crash or any other reason, the background process will not clear it very quickly as it has to take care of missed refresh session calls.

>How aggressively a vendor wants to detect abandoned sessions?

To detect abandoned sessions as soon as possible, a vendor needs to call the refresh API at shorter interval. The vendor might not consider missed refresh calls due to network error or might consider just one missed refresh API call. Also he needs to run background process at aggressive periodic interval.

>What is network delay and record insertion cost for refresh session?

Though the refresh API is synchronous but there will be some minor delay due to network communication and record processing cost, it has to be considered.

Example: A vendor decides to call the refresh API in every 30 minutes. He permits one missed refresh API call and he expects network delay of 5 minutes so the total is 65 minutes. If background process runs every 30 minutes and user session crashed just after calling the login API, then in the worst case session will be cleared in 65 + 30 = 95 minutes.

Number of Days to Consider Records: 30 days[Fixed].

There can be millions of records in usage history table, considering all records will be a performance bottleneck. This value is fixed to 30 days.

NOTE The value of the property should be greater than the sum of license session timeout, background process periodic interval, and usage sync frequency.