Re: (ITS#3979) glue mixtures can confuse slapadd

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Howard Chu writes:
> Yes. Although "async" is still unimplemented, and I'm wondering if it
> is useful in its present definition. Given the need to enforce
> sizelimits, I don't think it's desirable to immediately fan out a
> search across all the subordinates. The search must be
> deterministically sequenced (top-down, breadth-first, whatever) so
> that two identical search requests with the same sizelimit return the
> identical result set, otherwise I think we'd break the data model.

I don't think so, though I haven't dug deeply.  All I know is that "The
SearchResultEntry and SearchResultReference PDUs may come in any order".
(RFC 2251 section 4.5.2.)

> On a slightly related topic, I do think it's desirable to be able to
> configure multiple subordinates as fractional peers, because that would
> be a big help for scaling.  (I.e. multiple backends with the same suffix,
> each only responsible for a portion of the total content.)  We might
> support this by adding an additional filter specifier to identify which
> backend is responsible for a given entry. Ideally the specifier would
> only depend on the entry's RDN, so that select_backend's signature
> remains unchanged. e.g.:

I'm not quite sure which operations you are scaling here...

Most of our searches do not use the full DN, so they'd have to search
all the databases.  So we use the "unchecked" limit to stop too general
searches.

> Unfortunately a simple scheme like this requires constant monitoring and
> frequent rebalancing. A better scheme would be to hash the DN and evenly
> distribute entries among all the peers. I guess we could hack this into
> a filter by creating a custom matching rule...

Another thing which might be useful is to have multi-attribute indexes
(including the use of the DN or a parent DN as the attribute), which
match if both the attributes match that of the search.

-- 
Hallvard