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-18.104.22.168-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)
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: 22.214.171.124
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:
If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)
to comment on this ticket.