directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacob S. Barrett (JIRA)" <>
Subject [jira] Commented: (DIRLDAP-71) CachingNormalizer exhibits concurrency flaw under load.
Date Mon, 21 Nov 2005 16:12:42 GMT
    [ ] 

Jacob S. Barrett commented on DIRLDAP-71:

Two things:
1) You can only remove the call to containsKey() if Normalizer.normalize() will never result
in a null value.  If it can return a null value then you must synchronize the around both
calls to get() and containsKey().

2) As I think about it more and look at the implementation of LRUMap the use of a R/W is a
bit more complicated.  Even on a get() call the internals of LRUMap are modified.  To do this
with a R/W you will have to internally get a W lock on the LRU list on every get(). Since
every read results in a write lock synchronize is sufficient and less complicated for this

> 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