[infinispan-issues] [JBoss JIRA] (ISPN-1822) Cache entry not evicted from memory on IBM JDK when another entry was loaded from a cache loader and maxEntries had been reached

[Martin Gencur (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754205#comment-12754205 ] 

Martin Gencur commented on ISPN-1822:
-------------------------------------

So I gave it another try and got much better results. The commit that fixes this issue is located at https://github.com/mgencur/infinispan/commit/575dbf1837803d4422725119082157e968f647d2

Some results from MapStressTest: https://gist.github.com/mgencur/4954139

The first two scenarios maintain the capacity <= 100000. The WriteOnMiss scenario leaves just a few redundant entries in the map after the test ends. I executed the same test also with 10-minute duration and it seems the number of redundant entries does not increase.

Other functional tests like LRUEvictionFunctionalTest or EvictionWithPassivationTest are passing now (fixes ISPN-2623 too).

I tested my solution with IBM JDK 7 64bit:

java version "1.7.0"
Java(TM) SE Runtime Environment (build pxa6470sr3-20121025_01(SR3))
IBM J9 VM (build 2.6, JRE 1.7.0 Linux amd64-64 20121024_126071 (JIT enabled, AOT enabled)


I will leave it to your judgment whether it's a good fix or not. IMO that's definitely better than the current behavior of ISPN.


                
> Cache entry not evicted from memory on IBM JDK when another entry was loaded from a cache loader and maxEntries had been reached
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ISPN-1822
>                 URL: https://issues.jboss.org/browse/ISPN-1822
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Eviction
>    Affects Versions: 5.1.0.FINAL
>         Environment: java version "1.6.0"
> Java(TM) SE Runtime Environment (build pxi3260sr9fp1-20110208_03(SR9 FP1))
> IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260sr9-20110203_74623 (JIT enabled, AOT enabled) ;
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build pxi3270-20110827_01)
> IBM J9 VM (build 2.6, JRE 1.7.0 Linux x86-32 20110810_88604 (JIT enabled, AOT enabled)
>            Reporter: Martin Gencur
>             Fix For: 5.3.0.Final
>
>
> This behavior is specific to IBM JDK (I tried JDK6 and 7), it works fine with Java HotSpot.
> Steps to reproduce the problem:
> 1) set maxEntries for eviction to 2 and algorithm e.g. to LRU
> 2) store 3 entries key1, key2, key3 to the cache (after that you can see that the cache contains only 2 entries - key2 and key3, the first one was evicted from memory)
> 3) call cache.get("key1")
> 4) PROBLEM - cache contains all key1, key2, key3 even though it should contain only 2 entries - only happens with IBM JDK (6 or 7 ..no matter)
> I'll shortly issue a pull request with a test to ispn-core

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira