[
https://issues.apache.org/jira/browse/OFBIZ-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673338#action_12673338
]
David E. Jones commented on OFBIZ-2186:
---------------------------------------
Philippe,
Please understand that what you're saying now is very different than what you
said before. I wasn't questioning your conclusion, I was just responding to
your statement that you opinion was that the non-synchronized get was the
problem: "IMHO the bug is a missing synchonized in get()".
I totally agree that if there is code that changes things it needs to be
synchronized, and we should look into that more, and how to isolate it so that
it is done only when the LRU list is used (which is not the common case, BTW).
Thank you for providing more detail and being more clear in your additional
comments.
This one was actually pretty easy, so I made some changes in SVN rev 744205
that should resolve the issue, and only have an effect on performance if there
is a size limit on the cache.
Please comment if this fixes the problem you're running into, and if so we can
close the issue... and if not we'll have to look into it more!
> 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.
