Bug 1399494 - [GSS 6.6.x] Memory leak with LIRS eviction strategy
Summary: [GSS 6.6.x] Memory leak with LIRS eviction strategy
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: JBoss Data Grid 6
Classification: JBoss
Component: Infinispan
Version: 6.6.1
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ---
Assignee: Tristan Tarrant
QA Contact: Martin Gencur
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-29 08:13 UTC by Ted Jongseok Won
Modified: 2020-01-17 16:16 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-12-02 16:36:41 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Reproducer (22.06 KB, application/zip)
2016-11-29 08:13 UTC, Ted Jongseok Won
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker ISPN-7246 0 Major Resolved Memory leak with LIRS eviction strategy 2019-08-07 02:33:42 UTC

Description Ted Jongseok Won 2016-11-29 08:13:15 UTC
Created attachment 1225686 [details]
Reproducer

Description of problem:
There is a memory leak with the default eviction strategy. It's a leak in org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8 with LIRS eviction strategy.
There are cache entries in org.infinispan.container.DefaultDataContainer.entries and its size are bigger than cache size after eviction occurred.
DefaultDataContainer.entries retain keys and values for evicted entries in the cache.
After full GC, DefaultDataContainer.entries size wasn't changed.
The following minimum reproducer exhibits a leak. Eviction is supposed to suppress OOME.
Infinispan 8.2.5.Final is the same.

Version-Release number of selected component (if applicable):
Infinispan 6.4.1.Final-redhat-1

How reproducible:
Please find the reproducer attachment.
* JDG 6.6.1 Library mode
* LIRS eviction strategy
* maxEntries is 10
* numberOfPut=160000
* Run Main class with heap size 32MB

Steps to Reproduce:
unzip reproducer.zip
cd reproducer
mvn clean compile dependency:copy-dependencies
java -Xms32m -Xmx32m -cp target/classes:target/dependency/\* -DmaxEntries=10 -DnumberOfPut=160000 Main >/dev/null

Actual results:
log4j:WARN No appenders could be found for logger (org.jboss.logging).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
Exception in thread "main" org.infinispan.commons.CacheException: java.lang.OutOfMemoryError: GC overhead limit exceeded
        at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:344)
        at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1610)
        at org.infinispan.CacheImpl.putInternal(CacheImpl.java:1081)
        at org.infinispan.CacheImpl.put(CacheImpl.java:1072)
        at org.infinispan.CacheImpl.put(CacheImpl.java:1655)
        at org.infinispan.CacheImpl.put(CacheImpl.java:253)
        at Main.runTest(Main.java:29)

Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "main"


Expected results:
log4j:WARN No appenders could be found for logger (org.jboss.logging).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.


Additional info:

Comment 2 wfink 2016-12-02 16:36:41 UTC
The LIRS policy is definitely complicated. More information can be found in the knowledgebase
https://access.redhat.com/solutions/2790451

As the current behaviour is expected the issue will be closed.


Note You need to log in before you can comment on or make changes to this bug.