Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Message-ID: <10308007.1166279383651.JavaMail.jira@brutus>
Date: Sat, 16 Dec 2006 06:29:43 -0800 (PST)
From: "Emmanuel Lecharny (JIRA)" <jira@apache.org>
To: dev@directory.apache.org
Subject: [jira] Closed: (DIRSERVER-800) Avoid normalization when searching
In-Reply-To: <2250620.1166277621073.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/DIRSERVER-800?page=all ]

Emmanuel Lecharny closed DIRSERVER-800.
---------------------------------------

    Resolution: Invalid

Pfewww... There is no problem at all. The normalization occurs only for non indexed values.

> Avoid normalization when searching
> ----------------------------------
>
>                 Key: DIRSERVER-800
>                 URL: http://issues.apache.org/jira/browse/DIRSERVER-800
>             Project: Directory ApacheDS
>          Issue Type: Improvement
>            Reporter: Emmanuel Lecharny
>            Priority: Critical
>             Fix For: 1.5.0
>
>
> Ok, this will be an huge improvment, but also a huge modification. Here is the rational :
> - each time we are searching for an entry using an attribute value, we are walking a B-Tree doing a comparizon between the given value and the stored value. if we have N values stored in the B-Tree, we will do something like Log2(N) comparizons. 
> - Now, we have to be aware that those comparisons must be done against the normalized value of the attribute, and using the assocaited MatchingRule. For instance, "Emmanuel", "EMMANUEL" and "emmanuel" are supposed to be the same value if there type is CommonName, so we must do an case insensitive comparison.
> - a first optimization is already implemented : the incoming value is normalized _before_ the search, so we avoid a systematic normalization of the incoming attribute
> - but we will normalized each values which have been found into the server
> - again, an optimization is implemented : a cache is used to store normalized values, so it happens that sometime, we just get the normalized value from the cache.
> - but this cache has a limited size, and as it is a cache, each time we want to hit it, a synchronization occurs, which will lead to some concurrent access to slowdown.
> At this point, the question is  :
> - why don't we store normalized values of attribute instead of simple values? The initial (not normalized) value is always present in the entry, so there is no need to keep it into the indexes.
> This optimization could have a huge impact if it appears that, under heavy loads, the cache synchronization leads to delayed access.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira