[JCS-158] NullPointerException in IndexedDiskCache.addToRecycleBin(...)

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: jcs-2.0-beta-1
• Fix Version/s: jcs-2.0-beta-2
• Component/s: Indexed Disk Cache
• Assignee: Thomas Vandahl
• Reporter: Wiktor N
• Created: 16/Jan/16 22:36
• Updated: 25/Dec/16 18:35
• Resolved: 17/Jan/16 15:48

Description

One of our users got the following exception:
java.lang.NullPointerException
at org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCache.addToRecycleBin(IndexedDiskCache.java:1181)
at org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCache$LRUMapSizeLimited.processRemovedLRU(IndexedDiskCache.java:1785)
at org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCache$LRUMapSizeLimited.processRemovedLRU(IndexedDiskCache.java:1684)
at org.apache.commons.jcs.utils.struct.AbstractLRUMap.put(AbstractLRUMap.java:344)
at org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCache$LRUMapSizeLimited.put(IndexedDiskCache.java:1732)
at org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCache$LRUMapSizeLimited.put(IndexedDiskCache.java:1684)
at org.apache.commons.jcs.utils.struct.AbstractLRUMap.putAll(AbstractLRUMap.java:187)
at org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCache.loadKeys(IndexedDiskCache.java:343)
at org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCache.initializeStoreFromPersistedData(IndexedDiskCache.java:286)
at org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCache.initializeKeysAndData(IndexedDiskCache.java:250)
at org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCache.<init>(IndexedDiskCache.java:182)
at org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCacheFactory.createCache(IndexedDiskCacheFactory.java:60)
at org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCacheFactory.createCache(IndexedDiskCacheFactory.java:33)

My guess is, that during cache initialization doOptimizeRealTime() spawned a new thread calling optimizeFile().

optimizeFile() does all actions governed by storageLock.writeLock(), but there are no guarantees, in which order addToRecycleBin() will see changes done by optimizeFile.

I see two solutions to this problem:
1. Protect addToRecycleBin using storageLock.readLock() to ensure the same order of reads and writes with optimizeFile
2. Use volatile keyword on doRecycle / recycle objects and use Java Memory Model guarantees to order writes and reads in this two methods

My feeling is that 1st solution is more coherent with current approach within JCS.