-
Bug
-
Resolution: Timed out
-
Low
-
None
-
7.2.0, 7.6.15, 7.13.9, 8.5.1
-
7.02
-
1
-
Severity 3 - Minor
-
2
-
Issue Summary
Methods in DefaultUserPickerSearchService take UserSearchParams or maxResults value as a parameter to most of the methods.
The Java doc on UserSearchParams says:
* @param maxResults the maximum number of results to retrieve. Use <code>null</code> for unlimited results.
However, inside DefaultUserPickerSearchService, there is an explicit check for the null value (and an explicit special value meaning unlimited results) that changes this value to MAX_MAX_RESULTS, which currently is equal to 1000:
private int normalizeRidiculousUserPickerLimits(Integer resultLimit) { if (resultLimit == null || resultLimit == EntityQuery.ALL_RESULTS) { return MAX_MAX_RESULTS; } else { return resultLimit; } }
This means that the only way to obtain more than 1000 users from the search is to explicitly provide a big number as maxResults.
This approach is problematic though, as it can cause a high memory usage due to the way Lucene will handle this number - it will eagerly create an array of the passed-in size, so a caller providing MAX_INTEGER value to the method will user over 8GBs of memory.
Steps to Reproduce
N/A
Expected Results
DefaultUserPickerSearchService supports unlimited search, according to the Java doc.
Actual Results
DefaultUserPickerSearchService returns at most 1000 users when unlimited search is requested.
Workaround
A workaround is to explicitly set maxResults to a high number.
Note that this will use a lot of memory due to Lucene eagerly creating data structures, even if the final search will return 0 results.
- causes
-
JRASERVER-65089 User search startAt parameter is not working
- Closed