Full_Name: Geert Hendrickx Version: 2.4.44 OS: Linux URL: http://www.openldap.org/lists/openldap-technical/201602/msg00094.html Submission from: (NULL) (2a02:1810:4d03:d00:18e9:3ca5:a68f:c7f4) We found an odd issue when using LDAP Admin (www.ldapadmin.org), which by defaults uses the paged results control (RFC 2696) to limit search results. This client initially issues an objectclass=* search with one-level scope to list the first-level objects/trees on the LDAP DIT, which you can then browse/expand by clicking on them. On a large db, we noticed this initial search hits the timelimit, even though the equivalent command line search is instant. I found the difference is in using the paged result control: ldapsearch -s one -E \!pr=100 objectclass=\* objectclass => slow ldapsearch -s one objectclass=\* objectclass => fast The slapd stats+trace logging of each is in attachment. Notice the large number of objects being skipped with "scope not okay" in the first, where this does not happen in the second. This slows down the search, and on a very large db, makes it exceed the configured 60 seconds timelimit. A third variant, setting the sizelimit explicitly, avoids the issue: ldapsearch -s one -E \!pr=100 -z 100 objectclass=\* objectclass => fast Is this expected behaviour?
Seems buggy
changed notes moved from Incoming to Software Bugs
Hi Geert, Can you confirm if this issue still occurs with OpenLDAP 2.5? A number of changes in this regard have been made to back-mdb.
Hi I can reproduce exactly the same behaviour with OpenLDAP 2.5.7, on a freshly slapadd'ed mdb.
(In reply to geert.hendrickx@telenetgroup.be from comment #4) > Hi > > I can reproduce exactly the same behaviour with OpenLDAP 2.5.7, on a freshly > slapadd'ed mdb. Target milestone for the fix is 2.7.0, so that's expected. ;)
I'll put needs review on it though so we can discuss. ;)
I can reproduce it on any sufficiently large db, both tree-structured or flat, given the right search scope.