On Feb 7, 2009, at 9:21 AM, ando@sys-net.it wrote:
mhardin@symas.com wrote:
Sorry for the out-of-sequence reply. I'll test and let you know what I find.
No problem. Note that if this is the cause of this issue, and, in any case, if you have some "range" attributes in your response, you still have an issue with those values.
Yes. I'm not sure what to do about them in the medium term. Not having slapd crash is a good first step, though :P
It seems that, in the spirit of OpenLDAP software, we could be relatively liberal in accepting those values provided we are able to consolidate them in a single entry with no ranges. Apparently, what the proxies could do is:
- whenever a range is obtained in a response
- iteratively query the server again for the same entry,
- requesting only that attribute for the next block of vals
- incrementally build the set of values
- return the consolidated entry
This MUST be configurable, and documented as a nasty, expensive and unnecessary hack.
I had thought it might be possible to craft this functionality as an overlay (we could call it "derange" :P), but I think you're right- it is more appropriate that it be something configurable in back-meta and back-ldap. This functionality is particularly interesting when one considers using Howard's nss_ov in conjunction with pcache and back- ldap communicating with directory servers that were never intended to handle the high loads that Unix/Linux name services can place on a directory server ;-)
The high cost of the iterative searches might be mitigated through use of pcache. I'm thinking the searches to consolidate the ranged attributes would happen anyway, so better to do them in the proxy and cache the results than make each individual client have to do them.
Cheers,
-Matt
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it