commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wiktor N (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCS-158) NullPointerException in IndexedDiskCache.addToRecycleBin(...)
Date Sun, 17 Jan 2016 16:07:39 GMT

    [ https://issues.apache.org/jira/browse/JCS-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103763#comment-15103763
] 

Wiktor N commented on JCS-158:
------------------------------

Great, thanks for quick fix

> NullPointerException in IndexedDiskCache.addToRecycleBin(...)
> -------------------------------------------------------------
>
>                 Key: JCS-158
>                 URL: https://issues.apache.org/jira/browse/JCS-158
>             Project: Commons JCS
>          Issue Type: Bug
>          Components: Indexed Disk Cache
>    Affects Versions: jcs-2.0-beta-1
>            Reporter: Wiktor N
>            Assignee: Thomas Vandahl
>             Fix For: jcs-2.0-beta-2
>
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message