directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephane Bailliez (JIRA)" <>
Subject [jira] Commented: (DIRLDAP-71) CachingNormalizer exhibits concurrency flaw under load.
Date Sat, 12 Nov 2005 00:04:03 GMT
    [ ] 

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 that it does not
accept null values to be normalized and that it should not return null.

> CachingNormalizer exhibits concurrency flaw under load.
> -------------------------------------------------------
>          Key: DIRLDAP-71
>          URL:
>      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:
For more information on JIRA, see:

View raw message