[Date Prev][Date Next]
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 => <=
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:
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?
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support