[jira] Issue Comment Edited: (OFBIZ-4220) Current implementation of UtilCache has a memory leak

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

    [ https://issues.apache.org/jira/browse/OFBIZ-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008845#comment-13008845 ] 

Philippe Mouawad edited comment on OFBIZ-4220 at 3/20/11 3:54 PM:
------------------------------------------------------------------

The main source for this leak is:
ExecutionPool registration.

Object retains lot of references to Caches that may be not be used anymore.
I made a test with 256m affected , and ExecutionPool retains through 164 Mo in an array of 1134867 elements.
I made a new test by commenting ExecutionPool.addPulse(line); in tryRegister and no OOM occurs.

>From my understanding:
- ExecutionPool is used to collect elements in the Cache and handle expiry 
- ExecutionPoolPulseWorker runs in N threads to cleanup the queue , where N is the number of processors

if I understand well I think issue comes from the fact that removed elements are still in Expiry Queue and in the test case PUT is too heavy (50 threads) while expiry threads are only 2.
But this test case mimics what may happen in real life.

Philippe
http://www.ubik-ingenierie.com

      was (Author: p.mouawad@ubik-ingenierie.com):
    There is another source for this leak in:
ExecutionPool registration.

Object retains lot of references to Caches that may be not be used anymore.
  
> Current implementation of UtilCache has a memory leak
> -----------------------------------------------------
>
>                 Key: OFBIZ-4220
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-4220
>             Project: OFBiz
>          Issue Type: Bug
>          Components: framework
>    Affects Versions: SVN trunk
>         Environment: ALL
>            Reporter: Philippe Mouawad
>              Labels: CACHE, LEAK, MEMORY
>         Attachments: TestMemoryLeak.java
>
>
> Hello,
> Since some time UtilCache has been updated to replace the WeakHashMap by a ConcurrentHashMap:
>     private static final ConcurrentHashMap<String, UtilCache<?, ?>> utilCacheTable = new ConcurrentHashMap<String, UtilCache<?, ?>>();
> I think this fix to concurrency issues has introduced a memory leak or at least a much bigger impact on Memory.
> Indeed descendent of AbstractCache (particularly AbstractEntityConditionCache, EntityListCache) tend to create many caches that do not need to always persist in time.
> The old WeakHashMap handled this by enabling them to disappear while today the Hard ref disables this.
> We made some load testing and current implementation ends with an OutOfMemory.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira