[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: inequality searches cause slapd to freeze



You'll note that my response that you reference only mentions OpenLDAP 2.3. OpenLDAP 2.2 is feature frozen, so nothing I talked about there will be added in 2.2. Also talking about what could be done is not the same as saying it will be done. I've made no other indexing changes in 2.3, nor is it in any of my plans.

The behavior you describe here sounds like a bug that should be fixed, but you should file an ITS for it. Also some more information would help, such as knowing exactly how many searches are issued before the hang occurs, and the gdb backtrace from the event. Also, since 2.2.24 is already out, it would be best if you can reproduce the hang on 2.2.24 before filing the ITS.

Jon Roberts wrote:

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




--
 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support