-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Low
-
None
-
Affects Version/s: 11.3.8, 10.3.24
-
Component/s: Project Administration - Users and Roles
-
None
-
10.03
-
1
-
Severity 2 - Major
-
6
Issue Summary
When a user opens the Issue → More → Watchers → “Select a user“ option which will open (/secure/popups/UserPickerBrowser.jspa) , the operation takes significant time or never completes, causing the HTTP thread to become stuck or cause instance instability.
Steps to Reproduce
- Set up a fresh Jira DC instance on 10.3.24 or 11.3.8 with a sample project
- Navigate to any issue and click More → Watchers → “Select a user” to open the UserPickerBrowser.jspa pop-up
- Note the load time; the pop-up opens quickly at this stage
- Add a user directory containing a large number of users (tested it with 30k users)
- Repeat step 2 open the Select a user pop-up again
- Observe a significant delay in the pop-up loading compared to step 3 (this could lead into performance issues on instances with higher project and user count)
Expected Results
The results are paginated and hence there should not be significant impact on the instance.
Actual Results
Observe a significant delay in the pop-up loading and performance impact is seen on large instances
The UserPickerBrowser action calls UserPickerFilter.getFilteredUsers() which, for each candidate user returned by the Lucene search, invokes userHasBrowseAccessToAnyProject(user).
This is likely determining whether the candidate user has browse access to at least one project in the entire instance, resulting in an O(users × projects) or O(users × nested groups) computation on every single search request.
Common Stack Trace (present in 100% of thread dump snapshots )
Jira 10.3.24 and 11.3.8: bottleneck via nested group scan:
com.atlassian.jira.web.action.admin.user.UserPickerBrowser.doExecute(UserPickerBrowser.java:80) com.atlassian.jira.web.action.admin.user.UserPickerBrowser.getBrowsableItems(UserPickerBrowser.java:118) com.atlassian.jira.issue.customfields.CustomFieldUtils.userHasBrowseAccessToAnyProject(CustomFieldUtils.java:565) com.atlassian.jira.security.ApplicationRequiredPermissionManager.checkUserHasApplicationOrElse() com.atlassian.jira.security.ApplicationRequiredPermissionManager.checkUserHasApplicationOrEmpty() com.atlassian.jira.security.ApplicationRequiredPermissionManager.getProjects() com.atlassian.jira.security.ApplicationRequiredPermissionManager.shouldUserHaveAccess() com.atlassian.jira.security.PublicAccessPermissionManager.checkPublicAccessEnabledOrElse() com.atlassian.jira.security.PublicAccessPermissionManager.checkPublicAccessEnabledOrEmpty() com.atlassian.jira.security.PublicAccessPermissionManager.getProjects() com.atlassian.jira.application.DefaultApplicationRoleManager.hasAnyRole() com.atlassian.jira.application.DefaultApplicationRoleManager.userHasRole() com.atlassian.jira.security.groups.DefaultGroupManager.getGroupsForUser() com.atlassian.jira.security.groups.RequestCachingGroupManager.isUserInGroup() com.atlassian.jira.user.JiraCrowdService.search() com.atlassian.crowd.manager.application.ApplicationServiceGeneric.searchNestedGroupRelationships() ← HOT com.atlassian.crowd.embedded.core.CrowdServiceImpl.searchNestedGroupRelationships()
Jira 11.3: bottleneck via per-project permission scheme check:
com.atlassian.jira.web.action.admin.user.UserPickerBrowser.doExecute(UserPickerBrowser.java:80) com.atlassian.jira.web.action.admin.user.UserPickerBrowser.getBrowsableItems(UserPickerBrowser.java:118) com.atlassian.jira.security.DefaultPermissionManager.getProjectObjectsWithPermission(DefaultPermissionManager.java:455) com.atlassian.jira.security.DefaultPermissionManager.lambda$getProjectObjectsWithPermission$0(DefaultPermissionManager.java:454) com.atlassian.jira.security.ThreadLocalCachingPermissionManager.hasPermission(ThreadLocalCachingPermissionManager.java:54) com.atlassian.jira.security.PermissionsCache.computePermissionIfAbsent(PermissionsCache.java:49) com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2189) com.atlassian.jira.security.WorkflowBasedPermissionManager.hasPermission(WorkflowBasedPermissionManager.java:114) com.atlassian.jira.security.DefaultPermissionManager.hasPermission(DefaultPermissionManager.java:187) com.atlassian.jira.permission.DefaultPermissionSchemeManager.hasSchemePermission(DefaultPermissionSchemeManager.java:468)
Workaround
Currently there is no known workaround for this behavior. A workaround will be added here when available