directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot ...@marcelot.net>
Subject Re: Questions regarding Aliases
Date Tue, 24 Apr 2012 12:22:02 GMT

On 24 avr. 2012, at 13:28, Emmanuel Lécharny wrote:
> Hi guys,
> 
> Aliases handling is one of the biggest challenge in LDAP, as it imposes a lot of constraints.
First of all, keep in mind that Alias support is not mandatory.
> 
> Some of the problem we have when dealing with Alaises are :
> - cycle detection : we should not allow the creation of an alias that causes a cycle
> - duplicated entry removals in searches : we shuld not return an entry that has already
been returned
> - unlinked aliases : when the aliased entry is removed, we should should handle it
> - subtree searches with aliases : we may have a very high nunber of entries to return
> - move operation : how do we handle the aliases modification when the aliased entries
is move ?
> - cross-partitions aliases : how do we handle them ?
> - replication of aliases
> 
> Right now, my concern is about duplicated entries removal and cycle detection, during
a search processing :
> 
> 1) Cycle detection :
> Should we assume that the cycles are detected during the alias creation ? Or should we
detect it while processing the search ? (I'm nclined to think that cycle are forbidden during
their creation)

I agree there should be a check during the creation of the entry (and move operations too,
I guess).

But, I think we also need to check for cycles during the evaluation of the search.
If we use a batch insert mode with the server turned off to insert a large number of entries
(even if we don't have such a possibility now, we might get it in a near future), we might
have this kind of inconsistencies in the database.
More importantly, if we don't have such a mechanism and we actually do get a cycle (for one
reason or another, shit happens), the server would be looping forever and the user would have
no other way than stop/restart the server (and pray for the same search request to never appears
again).

> 2) duplicated entries removal
> I don't see any other way but storing a hash of all the UUID we already have transmitted,
and to check when we have a new candidate if this candidate has already been processed. This
is potentially *extremely* costly, if we have millions of entries (even if there is a size
limit, which protects us from a OOM, because this size limit is not enforced for the manager
user).
> Is there a better way ?

I had the same mechanism in mind. Costly, but at some point, you need this knowledge of what
entries have already been returned.

> 3) Current Aliases index
> I didn't have time to check what those index are used for, so if someone can give me
a quick heads up, that would save me a few days of code diging…

Sorry, I have no idea… :(

Regards,
Pierre-Arnaud

> Many thanks !
> 
> -- 
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
> 


Mime
View raw message