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

Re: limits on internal searches

> We need to be careful that a user, by selection of sync search
> over a plain search, cannot bypass limits which normally would
> apply.

OK; then my fix might be oveconservative.  In any case, I think at some
point in sync code there must be some dealing with (mostly size) limits,
because by monitoring what happens with test017, I was seeing weird
things, like counters going negative before being redirected to internal
searches.  The limits API is designed to deal with limits as they come
from do_search(), which parses them according to the protocol, and thus
they must be in the range 0..maxInt.  At the moment I'm unable to clearly
understand what the sync code is doing in there, but we need to consider
this aspect.

Ciao, Ando.

> Kurt
> At 07:59 AM 6/19/2004, Pierangelo Masarati wrote:
>>I've run into a problem with test017 which is currently failing for HEAD
>>after I added some consistency checks on the values of search limits.
>>I'm about to fix it, but I found out that some syncrepl code is checking
>>search limits before running internal searches.  Is it intended?  I mean,
>>is there any reason the identity that performs an internal search needs
>> to
>>check if any limits are set?  In that case, I strongly suggest any time
>> limits
>>are checked, an appropriate value is provided to fields op->ors_tlimit
>>and op->ors_slimit.  By protocol, these fields can only have values >= 0,
>>so if theey're set to SLAP_NO_LIMIT (= -1) it means they're being used
>>in an internal search that requirs no limitations.  Otherwise, please set
>>them to 0 (no specific limit required, incurring in soft limits if any)
>>or to a positive value (e.g. 1 is used for auth{cz} related internal
>> searches
>>because strictly one value is required.
>>   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497

Pierangelo Masarati

    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497