On 6/14/11 3:26 PM, Stefan Seelmann wrote:
There are a few steps we also have to fulfill :
- create an Alias cache ( I thought we had one, but in fact, we have the
opposite : a notAliasCache in the ExceptionInterceptor)
I wonder why we need an alias cache? For fast lookup of the search
base in case the "find" bit is set?
Good point... As soon as we fetch an alias, we just have to check its OC
to see if it's an alias, or not.
- create an AliasInterceptor to manage the Add and Delete operations done on
alias entries (and also move, rename and combined ops)
You mean that interceptor is used to update the cache, right?
Right. But if we don't need a cache, we don't either need this interceptor.
I will keep it atm to insolate the search filter in charge of detecting
the cycle.
The Alias index removal will be done at the end.
Ok.
Two other issues I see with the new algorighm:
- It is efficient if there are only few aliases. But if a user adds
million of alias entries we may get a memory problem.
If a user adds millions of Alias entries, he will have issues with any
LDAP server, I guess. And it's very unlikely to happen...
What we can do is to decide that we don't check for cycle once we have
more than, say, 10 aliases in the search alias cache.
I just want to
mention that to make clear that such an issue may occur. I don't think
it makes sense to create so many alias entries, but I saw an example
where group membership was implemented using aliases...
Make sense.
- It is possible that duplicates occur, for example if an alias
enlarges the initial search scope by pointing to a parent of the
initial search base. I think duplicates can be avoided by tracking
each search base and filter result enties within already processed
search bases.
Duplicate should not occur if we store the root DN in the search alias
cache : we will meet it at some point if the alias point to a parent.
Thanks for your feedback, it's very valuable.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
