[ http://issues.apache.org/jira/browse/DIRLDAP-71?page=comments#action_12358156 ]
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 block. > 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
