[Date Prev][Date Next]
Re: (ITS#5927) assertion error when using pcache
On Feb 8, 2009, at 1:26 PM, Pierangelo Masarati wrote:
> email@example.com wrote:
>> On Feb 7, 2009, at 9:21 AM, firstname.lastname@example.org wrote:
>>> email@example.com wrote:
>>>> Sorry for the out-of-sequence reply. I'll test and let you know
>>>> what I
>>> No problem. Note that if this is the cause of this issue, and, in
>>> case, if you have some "range" attributes in your response, you
>>> 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
> Are you confirming that the original issue is fixed?
Unfortunately not. The morning I tested the fix you checked into HEAD
and still got an assertion error in pcache at the same point when
caching group objects that contain range specifiers. I have core files
and would be happy to provide additional information if you need it.
>>> 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
>>> 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.
> You can't handle that with an overlay, since the message containing
> this type of response is received by the proxy backends and would
> fail parsing unless handled there :).
So I've learned :)
>> 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.
> Yes. Another possible issue is that we'd probably need to work a
> symmetric solution in those cases where a request needs values to be
> broken in ranges in order to be accepted by AD.
Ugh. I suppose so, although my interest in that is relatively low at
> Ing. Pierangelo Masarati
> OpenLDAP Core Team
> SysNet s.r.l.
> via Dossi, 8 - 27100 Pavia - ITALIA
> Office: +39 02 23998309
> Mobile: +39 333 4963172
> Fax: +39 0382 476497
> Email: firstname.lastname@example.org