directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacob S. Barrett (JIRA)" <directory-...@incubator.apache.org>
Subject [jira] Commented: (DIRLDAP-71) CachingNormalizer exhibits concurrency flaw under load.
Date Mon, 21 Nov 2005 17:28:43 GMT
    [ http://issues.apache.org/jira/browse/DIRLDAP-71?page=comments#action_12358168 ] 

Jacob S. Barrett commented on DIRLDAP-71:
-----------------------------------------

I think I would have left LRUMap alone and just synchronized when it is in use.  There might
be other places where LRUMap will be used and has no need for synchronization.

With the synchronization you added inside of LRU map there is still a chance for concurrent
modification that might result in some "strangeness".  Not all modifications are synchronized,
see the put() operation where the LRU is not full, the call to super is not synchronized.
 Also since none of the inherited methods are synchronized it is possible to have one thread
modifying the structure while another is reading it. Something like containsKey() could barf
when looking at the underlying HashMap if it changes.



> 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
>     Assignee: Emmanuel Lecharny
>  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


Mime
View raw message