[ 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
