[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
9:33 a.m.
Martin Gencur created ISPN-1822:
-----------------------------------
Summary: 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
Assignee: Manik Surtani
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:37 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Martin Gencur commented on ISPN-1822:
-------------------------------------
Works fine with OpenJDK 6 as well.
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
Assignee: Manik Surtani
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:53 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Martin Gencur commented on ISPN-1822:
-------------------------------------
A test for this can be found here: https://github.com/infinispan/infinispan/pull/919
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
Assignee: Manik Surtani
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:19 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Martin Gencur commented on ISPN-1822:
-------------------------------------
Manik, it seems like on Oracle JDK when I set maxEntries to 2, it is really 2. However on
IBM JDK when I set maxEntries to 2, it actually ends up with 4 (the least power of two
larger than selected value - as described in docs -
http://docs.jboss.org/infinispan/5.1/apidocs/org/infinispan/config/Config...).
Is this difference in behavior expected?
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
Assignee: Manik Surtani
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:14 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Manik Surtani commented on ISPN-1822:
-------------------------------------
The difference in behaviour certainly is odd. It may be due to the CHM implementation
differences in the two jdks. Could you start a thread on infinispan-v about this, and
let's see what's going on?
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
Assignee: Manik Surtani
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:14 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Manik Surtani edited comment on ISPN-1822 at 2/3/12 6:14 AM:
-------------------------------------------------------------
The difference in behaviour certainly is odd. It may be due to the CHM implementation
differences in the two jdks. Could you start a thread on infinispan-dev about this, and
let's see what's going on?
was (Author: manik):
The difference in behaviour certainly is odd. It may be due to the CHM implementation
differences in the two jdks. Could you start a thread on infinispan-v about this, and
let's see what's going on?
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
Assignee: Manik Surtani
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:16 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Manik Surtani updated ISPN-1822:
--------------------------------
Fix Version/s: 5.2.0.ALPHA1
5.2.0.FINAL
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
Assignee: Manik Surtani
Fix For: 5.2.0.ALPHA1, 5.2.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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:23 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Galder Zamarreño updated ISPN-1822:
-----------------------------------
Fix Version/s: 5.2.0.ALPHA3
(was: 5.2.0.ALPHA2)
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
Assignee: Manik Surtani
Fix For: 5.2.0.ALPHA3, 5.2.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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:55 p.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Mircea Markus updated ISPN-1822:
--------------------------------
Fix Version/s: 5.2.0.Alpha4
(was: 5.2.0.Alpha3)
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
Assignee: Manik Surtani
Fix For: 5.2.0.Alpha4, 5.2.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
10:09 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Galder Zamarreño commented on ISPN-1822:
----------------------------------------
@Martin, what about we hook up a workaround for this issue?
We could find out if we're running the IBM JDK, and if the user sets the maxEntries to
2, internally transform it to 1 so that it behaves as you'd expect. IOW, find the
nearest lowest power of 2 and set that instead of what the user defines, WDYT?
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
Assignee: Manik Surtani
Fix For: 5.2.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
10:09 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Galder Zamarreño updated ISPN-1822:
-----------------------------------
Fix Version/s: (was: 5.2.0.Alpha4)
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
Assignee: Manik Surtani
Fix For: 5.2.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
10:21 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Martin Gencur commented on ISPN-1822:
-------------------------------------
That could be a possibility. IIRC, this is just a problem with LRU strategy, not LIRS, so
take it into account.
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
Assignee: Manik Surtani
Fix For: 5.2.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
11:13 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Galder Zamarreño commented on ISPN-1822:
----------------------------------------
@Martin, you wanna have a go at creating a workaround patch for this? :)
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
Assignee: Manik Surtani
Fix For: 5.2.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
1:23 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Martin Gencur commented on ISPN-1822:
-------------------------------------
OK :)
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
Assignee: Manik Surtani
Fix For: 5.2.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
1:23 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Martin Gencur reassigned ISPN-1822:
-----------------------------------
Assignee: Martin Gencur (was: Manik Surtani)
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
Assignee: Martin Gencur
Fix For: 5.2.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
7:20 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Martin Gencur commented on ISPN-1822:
-------------------------------------
Hmm, it seems that setting lower max entries limit on IBM JDK does not help. I did the
following change in
BoundedConcurrentHashMap but the number of entries in the cache was still exceeded during
the test:
{code:java}
int previousPowerOfTwo = 0; //new line
while (cap < c) {
previousPowerOfTwo = cap; //new line
cap <<= 1;
}
...
for (int i = 0; i < this.segments.length; ++i) {
this.segments[i] = new Segment<K, V>(cap, previousPowerOfTwo /*changed param*/,
DEFAULT_LOAD_FACTOR, evictionStrategy, evictionListener);
}
{code}
The cap parameter sets the size of a segment and previousPowerOfTwo sets the limit when
eviction should be executed.
The previousPowerOfTwo is always lower and what was there previously but setting this
limit to a lower number does not
help. There are still more entries in the cache that should be.
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
Assignee: Martin Gencur
Fix For: 5.2.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
7:22 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Martin Gencur edited comment on ISPN-1822 at 9/14/12 8:20 AM:
--------------------------------------------------------------
Hmm, it seems that setting lower max entries limit on IBM JDK does not help. I did the
following change in BoundedConcurrentHashMap but the number of entries in the cache was
still exceeded during the test:
{code:java}
int previousPowerOfTwo = 0; //new line
while (cap < c) {
previousPowerOfTwo = cap; //new line
cap <<= 1;
}
...
for (int i = 0; i < this.segments.length; ++i) {
this.segments[i] = new Segment<K, V>(cap, previousPowerOfTwo /*changed param*/,
DEFAULT_LOAD_FACTOR, evictionStrategy, evictionListener);
}
{code}
The cap parameter sets the size of a segment and previousPowerOfTwo sets the limit when
eviction should be executed. The previousPowerOfTwo is always lower and what was there
previously but setting this limit to a lower number does not help. There are still more
entries in the cache that should be.
was (Author: mgencur):
Hmm, it seems that setting lower max entries limit on IBM JDK does not help. I did the
following change in
BoundedConcurrentHashMap but the number of entries in the cache was still exceeded during
the test:
{code:java}
int previousPowerOfTwo = 0; //new line
while (cap < c) {
previousPowerOfTwo = cap; //new line
cap <<= 1;
}
...
for (int i = 0; i < this.segments.length; ++i) {
this.segments[i] = new Segment<K, V>(cap, previousPowerOfTwo /*changed param*/,
DEFAULT_LOAD_FACTOR, evictionStrategy, evictionListener);
}
{code}
The cap parameter sets the size of a segment and previousPowerOfTwo sets the limit when
eviction should be executed.
The previousPowerOfTwo is always lower and what was there previously but setting this
limit to a lower number does not
help. There are still more entries in the cache that should be.
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
Assignee: Martin Gencur
Fix For: 5.2.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
9:29 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Martin Gencur commented on ISPN-1822:
-------------------------------------
Entries are not evicted properly because method
removeEldestEntry(Map.Entry<HashEntry<K,V>,V> eldest), which is
java.util.LinkedHashMap's method overridden in LRU class, is occasionaly not called
from within LinkedHashMap implementation in IBM JDK. This does not happen with Oracle JDK
nor OpenJDK. I'll investigate further but right now it seems it's a problem of
LinkedHashMap in IBM JDK.
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
Assignee: Martin Gencur
Fix For: 5.2.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
9:50 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Martin Gencur updated ISPN-1822:
--------------------------------
Comment: was deleted
(was: Entries are not evicted properly because method
removeEldestEntry(Map.Entry<HashEntry<K,V>,V> eldest), which is
java.util.LinkedHashMap's method overridden in LRU class, is occasionaly not called
from within LinkedHashMap implementation in IBM JDK. This does not happen with Oracle JDK
nor OpenJDK. I'll investigate further but right now it seems it's a problem of
LinkedHashMap in IBM JDK.)
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
Assignee: Martin Gencur
Fix For: 5.2.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
7:19 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Martin Gencur commented on ISPN-1822:
-------------------------------------
After more debugging, I got to the root cause. The problem is in IBM's implementation
of LinkedHashMap. The LinkedHashMap holds its data in an array called elementData. When
LinkedHashMap calls putImpl and the number of elements in the array is higher than the
limit, it performs a rehash. The next call to createHashedEntry() (inside putImpl) creates
a new entry but this entry is sometimes stored in a place of an existing element (due to
incorrectly generated hash/index value) instead of appending it to the elementData array.
As a result, the LinkedHashMap holds wrong data (e.g. 2 elements instead of 3, and wrong
ones) and the consecutive call to removeEldestEntry returns true which means that another
element is removed from the elementData array at the end of putImpl() in LinkedHashMap
(i.e. elementData contains 1 element instead of 2, and wrong one).
We spotted this defect only with small numbers of elements in the cache. However, the
nature of the defect signifies that this could easily happen even with higher number of
elements in the cache and thus evicting wrong entries.
I cannot see any obvious fix/workaround for Infinispan, apart from fixing the bug in IBM
JDK. So I would suggest not using eviction with IBM JDK.
The suspected code in IBM's LinkedHashMap: https://gist.github.com/3749342
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
Assignee: Martin Gencur
Fix For: 5.2.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
7:23 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Martin Gencur edited comment on ISPN-1822 at 9/19/12 8:23 AM:
--------------------------------------------------------------
After more debugging, I got to the root cause. The problem is in IBM's implementation
of LinkedHashMap. The LinkedHashMap holds its data in an array called elementData. When
LinkedHashMap calls putImpl and the number of elements in the array is higher than the
limit, it performs a rehash. The next call to createHashedEntry() (inside putImpl) creates
a new entry but this entry is sometimes stored in a place of an existing element (due to
incorrectly generated hash/index value) instead of appending it to the elementData array.
As a result, the LinkedHashMap holds wrong data (e.g. 2 elements instead of 3, and wrong
ones) and the consecutive call to removeEldestEntry returns true which means that another
element is removed from the elementData array at the end of putImpl() in LinkedHashMap
(i.e. elementData contains 1 element instead of 2, and wrong one).
We spotted this defect only with small numbers of elements in the cache. However, the
nature of the defect signifies that this could easily happen even with higher number of
elements in the cache and thus evicting wrong entries.
I cannot see any obvious fix/workaround for Infinispan, apart from fixing the bug in IBM
JDK. Or rewriting the whole LRU class without using LinkedHashMap. So I would suggest not
using eviction with IBM JDK (only for LRU, LIRS works well because it does not extend
LinkedHashMap).
The suspected code in IBM's LinkedHashMap: https://gist.github.com/3749342
was (Author: mgencur):
After more debugging, I got to the root cause. The problem is in IBM's
implementation of LinkedHashMap. The LinkedHashMap holds its data in an array called
elementData. When LinkedHashMap calls putImpl and the number of elements in the array is
higher than the limit, it performs a rehash. The next call to createHashedEntry() (inside
putImpl) creates a new entry but this entry is sometimes stored in a place of an existing
element (due to incorrectly generated hash/index value) instead of appending it to the
elementData array.
As a result, the LinkedHashMap holds wrong data (e.g. 2 elements instead of 3, and wrong
ones) and the consecutive call to removeEldestEntry returns true which means that another
element is removed from the elementData array at the end of putImpl() in LinkedHashMap
(i.e. elementData contains 1 element instead of 2, and wrong one).
We spotted this defect only with small numbers of elements in the cache. However, the
nature of the defect signifies that this could easily happen even with higher number of
elements in the cache and thus evicting wrong entries.
I cannot see any obvious fix/workaround for Infinispan, apart from fixing the bug in IBM
JDK. So I would suggest not using eviction with IBM JDK.
The suspected code in IBM's LinkedHashMap: https://gist.github.com/3749342
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
Assignee: Martin Gencur
Fix For: 5.2.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
3:23 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Galder Zamarreño commented on ISPN-1822:
----------------------------------------
@Martin, couldn't we make a copy of the Sun/OpenJDK's LinkedHashMap which we know
it works fine, and when IBM JDK is used, use that copy instead of the one provided by the
JDK? Sounds like an easy workaround, doesn't it?
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
Assignee: Martin Gencur
Fix For: 5.2.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
5:19 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Martin Gencur commented on ISPN-1822:
-------------------------------------
@Galder, I'm working on a solution. I'll just extend HashMap instead of
LinkedHashMap (the LRU class extends it) and maintain doubly linked list (similar to what
LinkedHashMap does). I've got it to work already, I just need to test it properly. If
that does not work, we can possibly use OpenJDK's impl. Not sure about licensing,
though.
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
Assignee: Martin Gencur
Fix For: 5.2.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
7:49 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Martin Gencur updated ISPN-1822:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1327
Here comes my patch for this issue.
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
Assignee: Martin Gencur
Fix For: 5.2.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
4:30 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Martin Gencur updated ISPN-1822:
--------------------------------
Status: Pull Request Sent (was: Pull Request Sent)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1332 (was:
https://github.com/infinispan/infinispan/pull/1327)
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
Assignee: Martin Gencur
Fix For: 5.2.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
2:10 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Tristan Tarrant updated ISPN-1822:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
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
Assignee: Martin Gencur
Fix For: 5.2.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
2:05 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Martin Gencur reopened ISPN-1822:
---------------------------------
Re-opening since the patch is not working absolutely correctly. Note that this affects
only IBM JDK, eviction on other JDKs works properly.
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
Assignee: Martin Gencur
Fix For: 5.2.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
11:14 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
Mircea Markus updated ISPN-1822:
--------------------------------
Fix Version/s: 5.2.1
(was: 5.2.0.Final)
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
Assignee: Martin Gencur
Fix For: 5.2.1
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
8:25 a.m.
[
https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin....
]
RH Bugzilla Integration updated ISPN-1822:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=818863
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
Assignee: Martin Gencur
Fix For: 5.2.1
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
4399
days inactive
4708
days old
infinispan-issues@lists.jboss.org
30 comments
6 participants
participants (6)
-
Galder Zamarreño (JIRA) -
Manik Surtani (JIRA)
-
Martin Gencur (JIRA)
-
Mircea Markus (JIRA)
-
RH Bugzilla Integration (JIRA)
-
Tristan Tarrant (JIRA)