[ http://issues.apache.org/jira/browse/DIRLDAP-71?page=comments#action_12358163 ]
Emmanuel Lecharny commented on DIRLDAP-71: ------------------------------------------ The Normalizers won't return null. If the value is null, the normalizer will not be called, and if the value is empty, the DeepTrimNormalizer (and toLower) have been modified to handle this specific situation, and now return an empty string (before, they returned null) on the 2nd point, Jacob, I think that the synchronization I added in the LRUMap implementation should protect the server from concurrent access to the lmist. It could be cool to double-check the modification though ! (http://svn.apache.org/viewcvs?rev=345925&view=rev) > 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
