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

Re: 8 hours tests ends with inconsistent DB.

paul k wrote:

While totally agreeing with your deployment strategies I would not count them as proper arguments for the matter at hand (benchmarking OL). I may be ignorant but I'd expect a poorly configured system to perform poorly and of course not doing things as you expect but not to misbehave or fail. If the underlying DB is not configured explicitely, fall back to sane defaults, if you hit the resource limits of hardware or whatever mechanism, the application should behave gracefully.

While there are many well-known techniques for gracefully dealing with resource shortages, the OpenLDAP code base (and the UMich code it derives from) were not originally written with these techniques in mind. It takes a substantial rewrite effort to get there. The OpenLDAP code in 2.2 is already much more resilient than the old UMich code, thanks to some substantial rewriting that has already been done.

To restate - given where the code started, fixing this is easier said than done, but it *is* being done. If you'd like it to happen faster, you know that help is always welcome. In the meantime, there's no substitute for a properly administered system.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support