[
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
