Understanding User Session Transactions and Instance Settings

[Allen Andreas]

Understanding User Session Transactions and Instance Settings

Within a ServiceNow instance, each user is associated with a "session" as well as a "session object". This all takes place on one application node (refer to a prior post I did about app nodes) where the user's session object exists. This is a platform feature known as: session affinity.

Within each session, a user can only queue a certain number of transactions at once. As of Tokyo, there's a default setting (known as "Max Waiters" and is set to '10') as to how many transactions a single user can have queued. There's also a default queue setting (known as "Queue Size Default Pool" and is set to '150') for all user sessions combined, as well.

The goal of the max waiters setting is to prevent one single user session from taking over the platform and monopolizing the transaction queue. This scenario can occur during the execution of an integration that may not be configured the best where it's set to execute many transactions all on the same session (known as sticky sessions) or when loading/working with poorly configured UI or Portal pages that have many widgets that all try to refresh at the same time.

If a user attempts to queue more than the instance property setting allows, any extra transactions will be rejected and will result in an odd user experience where transactions will appear to fail and pages will only half load.

***ADVISEMENT*** - Adjusting the default values for these two settings is not commonly recommended and you should discuss any performance issues with ServiceNow Support if you're thinking of changing them. These system properties are usually not created/visible and would only be created if you were going to change the default values.

The system properties are:

• "Max Waiters" (Default value of 10): com.glide.request.max_waiters
• "Queue Size Default Pool" (Default value of 150): glide.servlet.thread.pool.queue_size_default_pool

Per a few support articles I found where there were other use cases for adjusting the Max Waiters property, ServiceNow Support has only recommended changing it to a max of 20 and nothing higher. Here's a few links to those articles for your review:

• Dependency map loading for hours
• Loading class manager, patterns hangs system
• Service catalog requests being ignored

If you enjoy ServiceNow content like this, check out and subscribe to my ServiceNow focused YouTube channel: Allenovation!