Asynchronous simple paged results requests could add too much load the server can handle. Adding a config parameter to restrict the requests.
cn=config nsslapd-maxsimplepaged-per-conn: INT
If nsslapd-maxsimplepaged-per-conn is configured with a positive integer, Asynchronous simple paged results requests per connection is limitted by the value. If the requests exceed the value, it returns LDAP_ADMINLIMIT_EXCEEDED.
If the value is -1, there is no limit (default behaviour). If the value is 0, a simple paged results is disabled.
git patch file (master) 0001-Ticket-48191-RFE-Adding-nsslapd-maxsimplepaged-per-c.patch
According to the RFC: http://www.ietf.org/rfc/rfc2696 {{{ A client may have any number of outstanding search requests pending, any of which may have used the pagedResultsControl. A server implementation which requires a limit on the number of outstanding paged search requests from a given client MAY either return unwillingToPerform when the client attempts to create a new paged search request, or age out an older result set. If the server implementation ages out an older paged search request, it SHOULD return "unwilling to perform" if the client attempts to resume the paged search that was aged out. }}} so return unwillingToPerform instead of administrativeLimitExceeded.
The server will accept a value of -2?
How does one turn off the limit, and go back to unlimited?
git patch file (master) -- fixed the return code to LDAP_UNWILLING_TO_PERFORM 0001-Ticket-48191-RFE-Adding-nsslapd-maxsimplepaged-per-c.2.patch
Rich, thank you for reviewing the patch.
Replying to [comment:3 rmeggins]:
According to the RFC: http://www.ietf.org/rfc/rfc2696 {{{ A client may have any number of outstanding search requests pending, any of which may have used the pagedResultsControl. A server implementation which requires a limit on the number of outstanding paged search requests from a given client MAY either return unwillingToPerform when the client attempts to create a new paged search request, or age out an older result set. If the server implementation ages out an older paged search request, it SHOULD return "unwilling to perform" if the client attempts to resume the paged search that was aged out. }}} so return unwillingToPerform instead of administrativeLimitExceeded. Done. The server will accept a value of -2? Yes. I've fixed the comment in the patch. {{{ If the value is negative, there is no limit (default behaviour). }}} How does one turn off the limit, and go back to unlimited? Yes. The nsslapd-maxsimplepaged-per-conn configuration is dynamic.
According to the RFC: http://www.ietf.org/rfc/rfc2696 {{{ A client may have any number of outstanding search requests pending, any of which may have used the pagedResultsControl. A server implementation which requires a limit on the number of outstanding paged search requests from a given client MAY either return unwillingToPerform when the client attempts to create a new paged search request, or age out an older result set. If the server implementation ages out an older paged search request, it SHOULD return "unwilling to perform" if the client attempts to resume the paged search that was aged out. }}} so return unwillingToPerform instead of administrativeLimitExceeded. Done.
The server will accept a value of -2? Yes. I've fixed the comment in the patch. {{{ If the value is negative, there is no limit (default behaviour). }}} How does one turn off the limit, and go back to unlimited? Yes. The nsslapd-maxsimplepaged-per-conn configuration is dynamic.
Reviewed by Rich (Thank you!!)
Pushed to master: cdb83c4..bed6f0d master -> master commit 5fd0cdf commit bed6f0d
Fixing a jenkins error...
Pushed to master: fe647ca..37eca99 master -> master commit 37eca99
attachment 0001-Ticket-48191-Move-CI-test-to-the-pr-suite-and-refact.patch
To ssh://git.fedorahosted.org/git/389/ds.git
Pushed to master: 73ff835..b9ab76a master -> master commit b9ab76a Author: Simon Pichugin spichugi@redhat.com Date: Mon Jul 18 13:54:41 2016 +0200
Metadata Update from @spichugi: - Issue assigned to nhosoi - Issue set to the milestone: 1.3.4.0
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/1522
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.