Some of the intensive asynchronous search requests fail with "unwilling to perform(53), Simple Paged Results Search already in progress on this connection".
Observed in 389-ds-base-1.2.11.15-11.el6.x86_64, but master also has the issue.
In the current code, SPR (simple paged results) is serialized and if a next page request comes in while the current page is being retrieved and returned, it returns 53 to the next page request.
git patch file (master) 0001-Ticket-47347-Simple-paged-results-should-support-asy.patch
Bug description: Simple paged results serialized the request even for a series of asynchronous search requests, and it returned error 53 (unwilling to perform) if the second request comes in while the first one is being processed.
Fix description: This patch implements the asynchronous support for the Simple paged results search. - Removed pagedresults_check_or_set_processing which was used to Simple paged results requests exclusive. Instead, pagedresults_lock is introduced to protect the PagedResults object from the other threads sharing the same cookie. - If any error including hitting the sizelimit or timelimit, search result set was released immediately in ldbm_back_ next_search_entry_ext, which could cause the race condition among multiple asynchronous search requests. To prevent it, the search result set is untouched if the operation is a Simple paged result search, and let its clean up function to handle it. - Sizelimit was evaluated in the accumulative way instead of on the each page size. For instance, if the sizelimit was 101 AND the page size is 100, as soon as getting the 2nd page, it hit the sizelimit and the search failed. This patch fixes it so that as long as the requested page size is less than 101, the requests successfully continue without getting an error 4 (LDAP_SIZELIMIT_EXCEEDED). To fulfill the requirement, the current size needs to be managed per operation instead of the search result set or PagedResults object. For the purpose, introduced o_pagedresults_sizelimit to Slapi_Operation. - When shutting down, connection_table_free could use backend callback (e.g., be_search_results_release). Therefore, moved be_cleanupall after connection_table_free. - Each Simple paged results helper functions checks if the operation is really a Simple paged result request control is associated with to prevent any unexpected behaviour.
Reviewed by Rich (Thank you!!)
Pushed to master: commit d53e822
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=957864
Pushed to 389-ds-base-1.3.1: commit 473fc77 Pushed to 389-ds-base-1.3.0: commit aad3acd Pushed to 389-ds-base-1.2.11: commit 96535a6
Metadata Update from @nhosoi: - Issue assigned to nhosoi - Issue set to the milestone: 1.2.11.22
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/684
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.