Re: (ITS#5927) assertion error when using pcache

[mhardin@symas.com]

On Feb 8, 2009, at 1:26 PM, Pierangelo Masarati wrote:

> mhardin@symas.com wrote:
>> 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
>
> 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  
>>> 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.
>
> 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  
this point.

>
>
> p.
>
>

-Matt

> 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
> -----------------------------------
>