Bug 1198452
| Summary: | LIRS eviction strategy fixes | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Data Grid 6 | Reporter: | Sebastian Łaskawiec <slaskawi> |
| Component: | Infinispan | Assignee: | Tristan Tarrant <ttarrant> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Martin Gencur <mgencur> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.4.0 | CC: | chuffman, jdg-bugs, vjuranek, wburns, wfink |
| Target Milestone: | ER1 | ||
| Target Release: | 6.4.1 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
In previous versions of Red Hat JBoss Data Grid, LIRS eviction can cause some elements to be evicted prematurely, resulting in data not being passivated to the cache store.
The eviction policies have been updated, and the data container now ensures atomicity when passivating and activating entries to address this issue.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-04-02 12:13:53 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1197847 | ||
| Bug Blocks: | |||
|
Description
Sebastian Łaskawiec
2015-03-04 07:55:58 UTC
Hi, I don't know whether it is a good idea to put a fix with 10000+ lines of code, which re-implemenents the whole logic of eviction, into a micro release. Hi, behaviour of BoundedEquivalentConcurrentHashMapV8StressTest seems to be little bit weird. For 1M of entries run smoothly, but for 10M with eviction strategy on fills the map forever (forever == 45min on my machine and then I gave up). I.e. for 10M of entries and more BoundedEquivalentConcurrentHashMapV8 seems unusable. Bellow is part of the stack trace. Will, could you please comment on that? Is this expected or any hint where could be the problem? (I had enough memory available, the process consumed 2 cores) Thanks Thread 4182: (state = BLOCKED) - org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8$LRUEvictionPolicy.createNewEntry(java.lang.Object, int, org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8$Node, java.lang.Object, org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8$EvictionEntry) @bci=28, line=519 (Compiled frame) - org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8.putVal(java.lang.Object, java.lang.Object, boolean) @bci=94, line=2406 (Compiled frame) - org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8.put(java.lang.Object, java.lang.Object) @bci=4, line=2393 (Compiled frame) - org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8StressTest.testRemovePerformance(int, java.util.Map, java.lang.String) @bci=74, line=35 (Compiled frame) - org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8StressTest.testLRURemovePerformance() @bci=33, line=82 (Interpreted frame) Vojtech, Just to clarify I am guessing you meant LRU eviction strategy (looking at the stack trace it seems to be) ? I am guessing this also affected LIRS ? Also do you happen to have the entire JVM stack trace ? The snippet here seems to be fine from what I can see. Also it seems you are using BoundedEquivalentConcurrentHashMapV8StressTest to test this? Is that correct ? I have run it quite a few times with 10M and haven't had an issue yet, the stack trace should help immensely. Sorry for the false alarm, it was caused by GC and misconfiguration of my JAVA heap (I setup bigger heap for maven itself instead of surefire forked process). Now everything runs smooth and new implementation is noticeably faster then the old one. |