[ http://issues.apache.org/jira/browse/DIRLDAP-71?page=comments#action_12358133 ]
Trustin Lee commented on DIRLDAP-71: ------------------------------------ So do we need to fork Doug Lea's concurrent API, or just depend on it? > 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
