Description
- sys_user
- sys_user_role
- sys_user_has_role
Steps to Reproduce
The defect affects instances that use User Criteria to control access to the items and categories in the Service Catalog within a domain-separated environment. The defect may cause very long upgrades and severe performance degradation. Any update to a record in the sys_user, sys_user_has_roles, or sys_user_grmember table will trigger the USER_CATEGORIES_CACHE cache flush. When enough of these triggers in quick succession, the system is unable to process the cache rebuild, slowing down the system and leading to unresponsive behavior. This impact grows by a factor based on the number of domains.
The defect occurs under the following scenarios:
- Upgrade issue when com.glide.role_management.inh_count is not enabled and then com.glide.role_management adds multiple entries to the sys_user_has_role table. This can happen if a plugin upgrade adds a role or roles to other role or roles that are assigned to a large number of users.
- Plugin activation com.glide.role_management.inh_count can run into this issue.
- When a user adds a role or roles to another role or roles that are assigned to a large number of users.
- LDAP imports to update users or user roles can be affected by this issue.
Workaround
If you are not using User Criteria, turn off glide.sc.use_user_criteria by setting it to false.
This property can be accessed directly via https://<instance_name>.service-now.com/sys_properties_list.do?sysparm_query=name%3Dglide.sc.use_user_criteria
Note: We do not recommend this workaround if you are using User Criteria for Service Catalog security. Upgrade to a fixed version listed in the Fixed In section below.
If the instance is migrating from Eureka and uses entitlements, the issue does not occur because the property is set to false during the upgrade.
Related Problem: PRB668555