Ticket #47347 - Simple paged results should support async search
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!!)
(cherry picked from commit d53e8221f77ac325123e3bb4f61cf6de67dce646)