|
|
|
Is the stack trace from 2.0.1 or 2.3. Please add a new stack trace for further debugging.
Sorry, the stack trace above is from 2.0.1 here is the stack trace from 2.3 (I've excluded my code before the putInCache call):
java.util.NoSuchElementException at java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:367) at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:376) at com.opensymphony.oscache.base.algorithm.LRUCache.removeFirst(LRUCache.java:149) at com.opensymphony.oscache.base.algorithm.LRUCache.removeItem(LRUCache.java:125) at com.opensymphony.oscache.base.algorithm.AbstractConcurrentReadCache.put(AbstractConcurrentReadCache.java:1563) at com.opensymphony.oscache.base.algorithm.AbstractConcurrentReadCache.put(AbstractConcurrentReadCache.java:863) at com.opensymphony.oscache.base.Cache.putInCache(Cache.java:615) at com.opensymphony.oscache.base.Cache.putInCache(Cache.java:569) Ethan, this problem should be fixed in the current CVS HEAD. Please give us feedback, if you havn't any problem anymore.
http://wiki.opensymphony.com/display/CACHE/CVS+and+Compiling+OSCache | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I see this exception in oscache 2.3 on java 1.5
I looked into the LRUCache code and found this method and comments :
protected void itemRetrieved(Object key) {
// Prevent list operations during remove
while (removeInProgress) {
try {
Thread.sleep(5);
} catch (InterruptedException ie) {
}
}
// We need to synchronize here because AbstractConcurrentReadCache
// doesn't prevent multiple threads from calling this method simultaneously.
synchronized (list) {
list.remove(key);
list.add(key);
}
}
If this method can be called in an unsynchronized way, don't you have to synchronize on "list" whenever it is accessed in LRUCache (ex. itemRemoved() and removeFirst() ), even if the method calling is syncronized?
Can anyone provide some insight into this