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

Re: 2.3.43, and a variety of problems.

On Fri, 18 Sep 2009, Francis Swasey wrote:
2.4 is not "stable" by any definition other than the OpenLDAP project has designated it so.
I would disagree with this. I'm not at all involved in the official project designations, and I can say that I gave a talk at Rutgers in March 2009 (2.4.15 at the time) saying that RE24 is suitable for production use. It's on all of my replicas in production, and has been for months. One of the large reasons it's not on my master is because I've been spending my "OpenLDAP time" on RE24 testing (for the entire community) rather than my own development.
I am still seeing people complaining about syncrepl problems. So, how about you developers stop adding all the new wiz-bang bells and whistles and concentrate on stability and performance?
Honestly, I think this sort of answers the whole point: we're talking about a fairly "small" project, and I'd rather see those limited resources applied to stability and performance moving forward. Backporting to RE23 would distract from time needed towards making a "perfect" RE24 (or RE25 or...).
I don't know how it would be taken if somebody wanted to open up "openldap-legacy" to attempt backports. My guess is it'd all be fine until there's some seriously incompatible change, at which point you'd either need a good dev team (to do a fork) or to say "this effort is over, go to RE++." The former is extremely tough to come by, and the latter is essentially where we are today, so from a pragmatic standpoint I might even argue we're as good as we can be with the current model.
Have you fixed the fact that 2.4 is so much slower than 2.3 as reported by Quanah two months ago yet?
Quanah already pointed this out to some extent: I find the performance comparisons fallacious. Part of RE24 development has revealed some fairly serious issues in back-bdb, and there's a lot more locking in the code now to account for that. The perceived speed of RE23 really doesn't matter if it can't produce proper results. After all, if you want *real* performance, just define mutex_lock/unlock to be noops. I guarantee you you'll get good ops/second, during the limited time it runs at least...