[jira] Commented: (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:comment-tabpanel&focusedCommentId=12679609#action_12679609 ] 

Philippe Mouawad commented on OFBIZ-2186:
-----------------------------------------

Hello M. Jones,
Thank you for taking into account this bug.
We tested the patch you proposed in production, the same problem occured, the size of LRUMap exceed the configured maxSize.
We tested the initial patch I proposed and the problem is solved, we did a voluntary heap dump using jmap, and the hprof file generated shows that the size of LRUMap is OK.

I hope you can take into account this remark as soon as possible.
Philippe
www.ubik-ingenierie.com

> 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, OfbizBug.zip
>
>
> 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.