[ http://issues.apache.org/jira/brows...235745
9 ]

Stephane Bailliez commented on DIRLDAP-71:
------------------------------------------

I might be missing something but there's no need to me to do a containsKey()
 call.
AFAIK you'll never get a null normalized value stored in the cache plus the 
containsKey() is pretty inefficient as it is iterating over all keys to find
 if it exists so you'll want to avoid that call.

The Normalizer interface should certainly be documented to make it clear tha
t it does not accept null values to be normalized and that it should not ret
urn null.

> 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 NullPointerExceptio
n.
This is really only reached when you have more than threads than the max cac
he size and therefore items in the cache are being purged.  The attached pat
h synchronizes the cache.  It would be better to use a R/W lock from JSR 166
 backport or something sim
ilar.

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

[ Post a follow-up to this message ]