FC3, OpenLDAP 2.2.23, BDB 4.2.52
In a previous post, I had discussed problems using filters with => <=
operators.
http://www.openldap.org/lists/openldap-software/200412/msg00166.html
In the response, Howard Chu indicated potential support for inequality
indexing on integer types. I later changed my attributes to integer
syntax, and upgraded to OpenLDAP 2.2.23. Recoding my clients to use
these filters again, I got pretty speedy performance (where loglevel
was 0), and so I made a mistaken assumption that the function had in
fact been implemented. The filters now look something like this:
(&(&(gospqualifier>=400624)(gospqualifier<=400634))(objectClass=gosp)(gosptype=verse))
Unfortunately, I have discovered that after running something like a
dozen of these searches without issue, slapd hangs permanently on the
next such request. I cranked up the logs (loglevel -1) to see what was
happening, and soon discovered that each such search leads to a an
iterative comparison of each and every verse entry (3779) to the
filter to determine matches. The logs, you might guess, are
voluminous. Since the performance sans logs is okay, that really
doesn't matter to me right now so much as the slapd crash, which the
logs don't explain other than to stop at a point immediately before
the inequality search commences (as compared to what I see for a
succesful inequality search).
I can recreate this same condition on a separate box running RH9,
OpenLDAP 2.2.23, BDB 4.2.52, so it seems systematic. Each inequality
search I perform is preceded by a request for the entry representing
the passage itself, but otherwise the directory is unoccupied.
Any ideas what might be happening here?
Jon Roberts
www.mentata.com