[jira] Updated: (OFBIZ-2186) OutOfMemory provoked by Cache overflow

["Philippe Mouawad (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OFBIZ-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Philippe Mouawad updated OFBIZ-2186:
------------------------------------

    Attachment: CacheLineTable-patch.txt

Addition of synchronized to get()

> OutOfMemory provoked by Cache overflow
> --------------------------------------
>
>                 Key: OFBIZ-2186
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2186
>             Project: OFBiz
>          Issue Type: Bug
>          Components: framework
>    Affects Versions: SVN trunk, Release Branch 4.0
>         Environment: Linux, JDK 1.5_15, Xmx set to 1156Mo
>            Reporter: Philippe Mouawad
>            Priority: Critical
>         Attachments: CacheLineTable-patch.txt
>
>
> In our production system, we had an OutOfMemoryError.
> I analyzed the generated Heap Dump and found the following:
> The cache entitycache.entity-list.default.ProductCategoryMember retains a heap of 369314128 Bytes.
> The LRUMap hold by this object is occupying this space (369314128) and this object has a stange state:
> - maxSize is set to 5000 (as set in the cache.properties)
> - size is 128930 => PROBLEM
> IN cache.properties:
> entitycache.entity-list.default.ProductCategoryMember.expireTime=3600000
> entitycache.entity-list.default.ProductCategoryMember.useSoftReference=true
> entitycache.entity-list.default.ProductCategoryMember.maxInMemory=5000
> entitycache.entity-list.default.ProductCategoryMember.maxSize=7500
> I analyzed the code of LRUMap and its usage in CacheLineTable and IMHO the bug is a missing synchonized  in get():
> public CacheLine<V> get(Object key) {
>         if (key == null) {
>             if (Debug.verboseOn()) Debug.logVerbose("In CacheLineTable tried to get with null key, using NullObject" + this.cacheName, module);
>         }
>         return getNoCheck(key);
>     }
> Since LRUMap extends LinkedHashMap, if you look at get method, it changes the state of the Map by calling e.recordAccess(this):
>     public V get(Object key) {
>         Entry<K,V> e = (Entry<K,V>)getEntry(key);
>         if (e == null)
>             return null;
>         e.recordAccess(this);
>         return e.value;
>     }
> So the default of synchronization corrupts the state of LRUMap which grows indefinitely
> I will submit a patch for this on the trunk.
> Philippe
> www.ubik-ingenierie.com

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.