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: <583643014.1132526725789.JavaMail.jira@ajax.apache.org>
Date: Sun, 20 Nov 2005 23:45:25 +0100 (CET)
From: "Emmanuel Lecharny (JIRA)" <directory-dev@incubator.apache.org>
To: dev@directory.apache.org
Subject: [jira] Commented: (DIRLDAP-71) CachingNormalizer exhibits concurrency
 flaw under load.
In-Reply-To: <1116515560.1131749762892.JavaMail.jira@ajax.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/DIRLDAP-71?page=comments#action_12358107 ] 

Emmanuel Lecharny commented on DIRLDAP-71:
------------------------------------------

It seems that there is a double flaw in this piece of code :
1) The cache.get( value ) does a cache.containsKey itself. The code should be :

        Object result = cache.get( value ) ;
        
        if ( result != null )
        {
            return result ;
        }
       ...
2) The cache is an instance of LRUMap, which is not synchronized, and which relies on a not synchronized HashMap. This LRUMap must be synchronized using Collection.synchronizedMap(...)

The containsKey method is not iterating over all keys, because the LRUMap is backed by a HashMap.

The Normalizer.normalize() will behave correctly when receiving a null value.


> CachingNormalizer exhibits concurrency flaw under load.
> -------------------------------------------------------
>
>          Key: DIRLDAP-71
>          URL: http://issues.apache.org/jira/browse/DIRLDAP-71
>      Project: Directory LDAP
>         Type: Bug
>   Components: Common
>     Versions: 0.9.3
>     Reporter: Jacob S. Barrett
>  Attachments: CachingNormalizer-Concurrency.patch
>
> CachingNormalizer doesn't have it's cache protected from concurrent modifications.  Under load a state is reached where cache.containsKey(key) is true but the result of cache.get(key) results in an unexpected null value and thus a NullPointerException.  This is really only reached when you have more than threads than the max cache size and therefore items in the cache are being purged.  The attached path synchronizes the cache.  It would be better to use a R/W lock from JSR 166 backport or something similar.

-- 
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