|
If you were logged in you would be able to see more operations.
|
|
|
|
Environment:
|
We use hibernate 3.0.5 with OSCache 2.2 final.
|
|
Issue Links:
|
Duplicate
|
|
This issue duplicates:
|
|
CACHE-188
removeEntry should update group mappings
|
|
|
|
|
Related
|
|
This issue relates to:
|
|
|
CACHE-181
addGroupMappings leads to inconsisten...
|
|
|
|
|
|
|
Taken from the forum: http://forums.opensymphony.com/thread.jspa?threadID=27539&tstart=0
The leak is in OSCache group, every time a entry with group is put into OSCache, the LRU cache will hold this entry which can be swappd out of memory, but at the same time entry key is put into a MAP(key is group, value is SET of entry keys), these entry keys can never be swapped out - it keeps growing ... until running out of memory.
From change log of OSCache 2.3, I don't see this problem to be mentioned - So I assume this problem is still there.
|
|
Description
|
Taken from the forum: http://forums.opensymphony.com/thread.jspa?threadID=27539&tstart=0
The leak is in OSCache group, every time a entry with group is put into OSCache, the LRU cache will hold this entry which can be swappd out of memory, but at the same time entry key is put into a MAP(key is group, value is SET of entry keys), these entry keys can never be swapped out - it keeps growing ... until running out of memory.
From change log of OSCache 2.3, I don't see this problem to be mentioned - So I assume this problem is still there. |
Show » |
|
Bug
Major
The problem is: cache object maximum number is controlled, but the memory usage of AbstractConcurrentReadCache.groups( HashMap, key is group-String, value is Set of cache keys ) is not controlled - this can eat all memory.
inside of AbstractConcurrentReadCache.put(Object key, Object value, boolean persist)
line 1587, it calls updateGroups(null, (CacheEntry) value, persist)
line 1881, it calls addGroupMappings(newValue.getKey(), addToGroups, persist)
to add a cache key into AbstractConcurrentReadCache.groups