Re: limits on internal searches

["Jong-Hyuk" <jongchoi@OpenLDAP.org>]

(2) is only for syncrepl_entry().
For syncrepl_del_nonpresent(), the current approach (1) looks more
appropriate than (3).
For syncrepl_entry(), if it does not violate the limit checking semantics,
I'll change it to (2).
- Jong-Hyuk

----- Original Message ----- 
From: "Pierangelo Masarati" <ando@sys-net.it>
To: "Jong-Hyuk" <jongchoi@OpenLDAP.org>
Cc: <openldap-devel@OpenLDAP.org>
Sent: Monday, June 21, 2004 1:22 AM
Subject: Re: limits on internal searches


>
> >
> >> 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.
> >
> > Yes, it is intended to apply the limits of the updatedn user.
> > The original intention was to apply the limit spec to the entire sync
> > operation consisting of multiple internal search operations.
> > op->ors_slimit
> > is decremented by one each time the internal search in syncrepl_entry()
> > finds the entry having the matching entryUUID. The idea was to impose
the
> > limit to a single sync operation in the consumer as it is in fact a
single
> > search in the provider side. If the sizelimit in the implementation
should
> > be only meaningful within a single internal search, we have the
following
> > options : 1) set op->ors_slimit to 0 and call limits_check() to honor
the
> > limit setting of updatedn in a single search; 2) set op->ors_slimit to 1
> > and
> > treat SIZELIMIT_EXCEEDED as an consistency error because entryUUID is
> > unique; or 3) just set op->ors_slimit to SLAP_NO_LIMIT. The current HEAD
> > is
> > doing 1), but it is less meaningful to honor the limit setting per
search
> > operation because the number of match is one at most.
>
> So we'd rather use (2), right?
>
> also, current HEAD was doing (1) in syncrepl_del_nonpresent(), but it was
> leaving the ors_{st}limit unset in syncrepl_entry(); I applied (1) there
> as well.
>
> Ando.
>
> -- 
> Pierangelo Masarati
> mailto:pierangelo.masarati@sys-net.it
>
>
>     SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497
>
>
>