February 2013 - 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

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin.... ] Martin Gencur reassigned ISPN-1822: ----------------------------------- Assignee: (was: Martin Gencur) > 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.2.2, 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

13 years, 1 month

1
0
0 / 0

[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

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin.... ] Martin Gencur commented on ISPN-1822: ------------------------------------- I've been trying to fix this issues but it seems I'm running in circles. My previous fix was running in single-threaded environment and therefore EvictionWithPassivationTest is passing. However, if MapStressTest is executed, there are always more entries left in the cache than expected. I simply got stuck with 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.2, 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2817) Create a locate() API on the Java Hot Rod client

by Manik Surtani (JIRA)

[ https://issues.jboss.org/browse/ISPN-2817?page=com.atlassian.jira.plugin.... ] Manik Surtani updated ISPN-2817: -------------------------------- Summary: Create a locate() API on the Java Hot Rod client (was: Expose locate(key) on the java RemoteCacheManager) Assignee: Manik Surtani (was: Mircea Markus) Description: A locate() API to allow Java clients to make use of the consistent hash present in a RemoteCache instance and return a String representation of the endpoints assigned to a particular key. Typical signature: {code} List<String> locate(Object key) {code} was:RemoteCache.locate(key) method would return the server endpoints (or/and the actual JGroups address?) where the given key maps (a sequence, first being the primary owner). Complexity: Medium Component/s: Distributed Cache (was: Transactions) > Create a locate() API on the Java Hot Rod client > ------------------------------------------------ > > Key: ISPN-2817 > URL: https://issues.jboss.org/browse/ISPN-2817 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache > Affects Versions: 5.2.1 > Reporter: Mircea Markus > Assignee: Manik Surtani > Priority: Critical > Fix For: 5.2.2, 5.3.0.Final > > > A locate() API to allow Java clients to make use of the consistent hash present in a RemoteCache instance and return a String representation of the endpoints assigned to a particular key. Typical signature: > {code} > List<String> locate(Object key) > {code} -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2796) ConcurrentCacheManagerTest.testConcurrentGetCacheCalls hangs the test suite (randomly)

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2796?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2796: -------------------------------- Assignee: Dan Berindei (was: Mircea Markus) > ConcurrentCacheManagerTest.testConcurrentGetCacheCalls hangs the test suite (randomly) > -------------------------------------------------------------------------------------- > > Key: ISPN-2796 > URL: https://issues.jboss.org/browse/ISPN-2796 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Affects Versions: 5.2.0.Final > Reporter: Adrian Nistor > Assignee: Dan Berindei > Fix For: 5.2.2, 5.3.0.Alpha1 > > Attachments: ConcurrentCacheManagerTest.log, stack.log > > -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2796) ConcurrentCacheManagerTest.testConcurrentGetCacheCalls hangs the test suite (randomly)

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2796?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-2796: ------------------------------------- [~dan.berindei] +1, well spotted > ConcurrentCacheManagerTest.testConcurrentGetCacheCalls hangs the test suite (randomly) > -------------------------------------------------------------------------------------- > > Key: ISPN-2796 > URL: https://issues.jboss.org/browse/ISPN-2796 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Affects Versions: 5.2.0.Final > Reporter: Adrian Nistor > Assignee: Dan Berindei > Fix For: 5.2.2, 5.3.0.Alpha1 > > Attachments: ConcurrentCacheManagerTest.log, stack.log > > -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2817) Expose locate(key) on the java RemoteCacheManager

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2817?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2817: -------------------------------- Fix Version/s: 5.2.1 > Expose locate(key) on the java RemoteCacheManager > ------------------------------------------------- > > Key: ISPN-2817 > URL: https://issues.jboss.org/browse/ISPN-2817 > Project: Infinispan > Issue Type: Feature Request > Components: Transactions > Affects Versions: 5.2.1 > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 5.2.1, 5.3.0.Final > > > RemoteCache.locate(key) method would return the server endpoints (or/and the actual JGroups address?) where the given key maps (a sequence, first being the primary owner). -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2817) Expose locate(key) on the java RemoteCacheManager

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2817?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2817: -------------------------------- Priority: Critical (was: Major) > Expose locate(key) on the java RemoteCacheManager > ------------------------------------------------- > > Key: ISPN-2817 > URL: https://issues.jboss.org/browse/ISPN-2817 > Project: Infinispan > Issue Type: Feature Request > Components: Transactions > Affects Versions: 5.2.1 > Reporter: Mircea Markus > Assignee: Mircea Markus > Priority: Critical > Fix For: 5.2.2, 5.3.0.Final > > > RemoteCache.locate(key) method would return the server endpoints (or/and the actual JGroups address?) where the given key maps (a sequence, first being the primary owner). -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2817) Expose locate(key) on the java RemoteCacheManager

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2817?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2817: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > Expose locate(key) on the java RemoteCacheManager > ------------------------------------------------- > > Key: ISPN-2817 > URL: https://issues.jboss.org/browse/ISPN-2817 > Project: Infinispan > Issue Type: Feature Request > Components: Transactions > Affects Versions: 5.2.1 > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 5.2.2, 5.3.0.Final > > > RemoteCache.locate(key) method would return the server endpoints (or/and the actual JGroups address?) where the given key maps (a sequence, first being the primary owner). -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2619) DistSyncCacheStoreNotSharedTest fails randomly

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2619?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2619: -------------------------------- Assignee: Galder Zamarreño (was: Mircea Markus) > DistSyncCacheStoreNotSharedTest fails randomly > ---------------------------------------------- > > Key: ISPN-2619 > URL: https://issues.jboss.org/browse/ISPN-2619 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Affects Versions: 5.2.0.Beta5 > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Labels: testsuite_stability > Fix For: 5.2.2, 5.3.0.Final > > > DistSyncCacheStoreNotSharedTest fails (pretty rarely) with this exception: > {noformat} > 09:29:51,069 ERROR (testng-DistSyncCacheStoreNotSharedTest:) [UnitTestTestNGListener] Test testAtomicPutIfAbsentFromNonOwner(org.infinispan.distribution.DistSyncCacheStoreNotSharedTest) failed. > java.lang.AssertionError > at org.infinispan.distribution.DistSyncCacheStoreNotSharedTest.testAtomicPutIfAbsentFromNonOwner(DistSyncCacheStoreNotSharedTest.java:293) > {noformat} > What happens is that at the end of the previous test there is a get() that goes remotely, and one of the ClusteredGetCommands (to node C) is delayed. The test framework then clears the cache store and the data container on node C, but the get command already had the entry in its context and will write it to the data container when it finishes executing, so that the data container is not empty when testAtomicPutIfAbsentFromNonOwner starts. > {noformat} > 09:29:51,033 TRACE (OOB-1,ISPN,NodeC-33167:) [CommandAwareRpcDispatcher] Attempting to execute command: ClusteredGetCommand{key=k2, flags=null} [sender=NodeB-52644] > 09:29:51,062 TRACE (testng-DistSyncCacheStoreNotSharedTest:) [DummyInMemoryCacheStore] Clear store > 09:29:51,062 DEBUG (testng-DistSyncCacheStoreNotSharedTest:) [TestingUtil] Cleaning data for cache 'dist' on a cache manager at address NodeC-33167 > 09:29:51,065 DEBUG (testng-DistSyncCacheStoreNotSharedTest:) [TestingUtil] removeInMemoryData(): dataContainerBefore == [] > 09:29:51,062 TRACE (OOB-1,ISPN,NodeC-33167:dist) [ReadCommittedEntry] Updating entry (key=k2 removed=false valid=true changed=true created=false value=value2] > 09:29:51,065 TRACE (OOB-1,ISPN,NodeC-33167:dist) [EntryWrappingInterceptor] Committed entry ReadCommittedEntry(64d90a46){key=k2, value=value2, oldValue=null, isCreated=false, isChanged=false, isRemoved=false, isValid=true} > 09:29:51,065 DEBUG (testng-DistSyncCacheStoreNotSharedTest:) [TestingUtil] removeInMemoryData(): dataContainerAfter == [] > {noformat} -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2522) The org.infinispan.statetransfer.StateTransferCacheLoaderFunctionalTest (StateTransferFunctionTest) tests fail periodically

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2522?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2522: -------------------------------- Assignee: Adrian Nistor (was: Mircea Markus) > The org.infinispan.statetransfer.StateTransferCacheLoaderFunctionalTest (StateTransferFunctionTest) tests fail periodically > --------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2522 > URL: https://issues.jboss.org/browse/ISPN-2522 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Reporter: Anna Manukyan > Assignee: Adrian Nistor > Labels: testsuite_stability > Fix For: 5.2.2, 5.3.0.Alpha1 > > > The following tests of org.infinispan.statetransfer.StateTransferCacheLoaderFunctionalTest class are failing periodically during JDG 6.1.0.ER3 build testing: > org.infinispan.statetransfer.StateTransferCacheLoaderFunctionalTest.testSTWithWritingNonTxThread > org.infinispan.statetransfer.StateTransferCacheLoaderFunctionalTest.testSTWithWritingTxThread > You can find the failure logs here: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > The same issue happens to org.infinispan.statetranser.StateTransferFunctionTest tests(the parent test class). > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... -- 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

13 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2013