[CMIS-769] CacheImpl is not thread safe (org.apache.chemistry.opencmis.client.bindings.cache.impl.CacheImpl)

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: OpenCMIS 0.10.0
• Fix Version/s: OpenCMIS 0.11.0
• Component/s: opencmis-client
• Assignee: Florian Müller
• Reporter: Trask Stalnaker
• Created: 19/Mar/14 08:33
• Updated: 19/Mar/14 16:13
• Resolved: 19/Mar/14 16:13

Description

We ended up with a thread stuck in an infinite loop at:

java.lang.Thread.State: RUNNABLE
java.util.LinkedHashMap.transfer(Unknown Source)
java.util.HashMap.resize(Unknown Source)
java.util.LinkedHashMap.addEntry(Unknown Source)
java.util.HashMap.put(Unknown Source)
org.apache.chemistry.opencmis.client.bindings.cache.impl.AbstractMapCacheLevel.put(AbstractMapCacheLevel.java:56)
org.apache.chemistry.opencmis.client.bindings.cache.impl.CacheImpl.put(CacheImpl.java:191)
org.apache.chemistry.opencmis.client.bindings.spi.atompub.LinkCache.addLink(LinkCache.java:133)

The issue seems to be that CacheImpl is using an access-ordered LinkedHashMap via LruCacheLevelImpl, and CacheImpl is using a ReentrantReadWriteLock to synchronize access to the LinkedHashMap, allowing multiple concurrent readers, which is ok for HashMap, but is not ok for an access-ordered LinkedHashMap, see the bolded sentence at http://docs.oracle.com/javase/7/docs/api/java/util/LinkedHashMap.html:

"In access-ordered linked hash maps, merely querying the map with get is a structural modification."