July 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3112) KeyAffinityService API - provide overload of getKeyForAddress()

by Ben Cotton (JIRA)

[ https://issues.jboss.org/browse/ISPN-3112?page=com.atlassian.jira.plugin.... ] Ben Cotton edited comment on ISPN-3112 at 7/8/13 1:29 PM: ---------------------------------------------------------- The resolution of this JIRA fixes what we believe is a KeyAffinityService API delinquency. I.e. When my DIST_SYNC Cache’s Node X (@t=0) generates an Affinity-Key ‘aK’ for a Natural-Key ‘nK’ via aK = kas.getCollocatedKey(nK); // aK guarantees that nk will be pinned at Node X cache.put(aK, V); // pin the nK’s VALUE (via aK) at Node X Later, from my Cache’s Node Y (@t=1) I want to now get() the nK’s VALUE that was pinned at Node X (@t=0) without having Node Y to have an available reference to the previously computed AffintyKey aK. I currently cannot do that with the 5.x ISPN API. We need ISPN-3112 resolved so that from Node Y (@t=1) I can simply code // get VALUE from pinned node with nK – no need for an ‘aK’ reference V = cache.get(kas.getKeyForAddress(this.getAddress(NodeX), nK); was (Author: ben.cotton_jpmorgan.com): The resolution of this JIRA fixes what we believe is a KeyAffinityService API delinquency. I.e. When my DIST_SYNC Cache’s Node X (@t=0) generates an Affinity-Key ‘aK’ for a Natural-Key ‘nK’ via aK = kas.getCollocatedKey(nK); // aK guarantees that nk will be pinned at Node X cache.put(aK, V); // pin the nK’s VALUE (via aK) at Node X Later, from my Cache’s Node Y (@t=1) I want to now get() the nK’s VALUE that was pinned at Node X (@t=0) without having Node Y to have an available reference to the previously computed AffintyKey aK. I currently cannot do that with the 5.x ISPN API. We need ISPN-3112 resolved so that from Node Y (@t=1) I can simply code // get VALUE from pinned node with nK – no need for an ‘aK’ reference V = cache.get(kas.getKeyForAddress(this.getAddress(NodeX), nK); > KeyAffinityService API - provide overload of getKeyForAddress() > --------------------------------------------------------------- > > Key: ISPN-3112 > URL: https://issues.jboss.org/browse/ISPN-3112 > Project: Infinispan > Issue Type: Enhancement > Components: Distributed Cache > Affects Versions: 5.3.0.Beta1 > Reporter: Ben Cotton > Assignee: Mircea Markus > Priority: Minor > > Add to the org.inifinispan.affinity.KeyAffinityService<K> interface an overload = > *K getKeyForAddress(Address address, K otherKey);* > //compute address specific version of 'otherKey' -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2990) L1ManagerImpl doesn't reliably invalidate with async caches

by Sebastian Tusk (JIRA)

[ https://issues.jboss.org/browse/ISPN-2990?page=com.atlassian.jira.plugin.... ] Sebastian Tusk commented on ISPN-2990: -------------------------------------- "For async caches the user should expect inconstancies by their nature" While short-lived inconsistencies would be expected with async caches I find persisting divergences surprising. With long timeouts or regular access to the data the cache returns wrong values indefinitely. > L1ManagerImpl doesn't reliably invalidate with async caches > ----------------------------------------------------------- > > Key: ISPN-2990 > URL: https://issues.jboss.org/browse/ISPN-2990 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.1.Final > Reporter: Sebastian Tusk > Assignee: William Burns > Priority: Minor > Labels: onboard > Fix For: 6.0.0.Final > > > B is owner of k,v1 > A has k,v1 in L1 > 1. TX: A puts k,v2 > 2. TX: A sends async PrepareCommand k,v2 to B (one-phase-commit) > 3. TX: A removes k,v1 from L1 > 4. A putForExternalRead k,v1 and has it in L1 again > 5. TX: B executes PrepareCommand k,v2 but doesn't send invalidation to origin > Result: A has k,v1 and B has k,v2 > Solution: For async caches send invalidation to origin too. > The problem is that the owner updates the cache entry asynchronously. This gives the origin of the transaction time to request the entry. Here an outdated version is received and placed in L1. The owner never invalidates the entry and as result the cache is inconsistent. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2161) InitiatorCrashPessimisticReplTest.testInitiatorNodeCrashesBeforeCommit fails randomly

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2161?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-2161: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/1958 > InitiatorCrashPessimisticReplTest.testInitiatorNodeCrashesBeforeCommit fails randomly > ------------------------------------------------------------------------------------- > > Key: ISPN-2161 > URL: https://issues.jboss.org/browse/ISPN-2161 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Reporter: Galder Zamarreño > Assignee: Pedro Ruivo > Labels: testsuite_stability > Fix For: 6.0.0.Alpha1, 6.0.0.Final > > Attachments: testInitiatorNodeCrashesBeforeCommit-0.log > > > Failed tests: testInitiatorNodeCrashesBeforeCommit(org.infinispan.lock.singlelock.replicated.pessimistic.InitiatorCrashPessimisticReplTest): expected key 'k' to be locked on cache Cache '___defaultcache'@InitiatorCrashPessimisticReplTest-NodeD-44283, but it is not -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2161) InitiatorCrashPessimisticReplTest.testInitiatorNodeCrashesBeforeCommit fails randomly

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2161?page=com.atlassian.jira.plugin.... ] Work on ISPN-2161 started by Pedro Ruivo. > InitiatorCrashPessimisticReplTest.testInitiatorNodeCrashesBeforeCommit fails randomly > ------------------------------------------------------------------------------------- > > Key: ISPN-2161 > URL: https://issues.jboss.org/browse/ISPN-2161 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Reporter: Galder Zamarreño > Assignee: Pedro Ruivo > Labels: testsuite_stability > Fix For: 6.0.0.Alpha1, 6.0.0.Final > > Attachments: testInitiatorNodeCrashesBeforeCommit-0.log > > > Failed tests: testInitiatorNodeCrashesBeforeCommit(org.infinispan.lock.singlelock.replicated.pessimistic.InitiatorCrashPessimisticReplTest): expected key 'k' to be locked on cache Cache '___defaultcache'@InitiatorCrashPessimisticReplTest-NodeD-44283, but it is not -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3306) RehashWithSharedCacheStoreTest.testRehashes fails randomly

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-3306: --------------------------------- Summary: RehashWithSharedCacheStoreTest.testRehashes fails randomly Key: ISPN-3306 URL: https://issues.jboss.org/browse/ISPN-3306 Project: Infinispan Issue Type: Bug Affects Versions: 5.3.0.Final Reporter: Pedro Ruivo Assignee: Mircea Markus Fix For: 6.0.0.Final Attachments: RehashWithSharedCacheStoreTest.testRehashes.tar.gz {code:java} java.lang.RuntimeException: Timed out waiting for rebalancing to complete on node RehashWithSharedCacheStoreTest-NodeB-2392, current topology is CacheTopology{id=8, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[RehashWithSharedCacheStoreTest-NodeB-2392, RehashWithSharedCacheStoreTest-NodeC-18606]}, pendingCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[RehashWithSharedCacheStoreTest-NodeB-2392, RehashWithSharedCacheStoreTest-NodeC-18606]}} at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:181) at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:191) at org.infinispan.distribution.rehash.RehashWithSharedCacheStoreTest.testRehashes(RehashWithSharedCacheStoreTest.java:76) ... {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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3306) RehashWithSharedCacheStoreTest.testRehashes fails randomly

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3306?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3306: ------------------------------ Attachment: RehashWithSharedCacheStoreTest.testRehashes.tar.gz attached trace logs > RehashWithSharedCacheStoreTest.testRehashes fails randomly > ---------------------------------------------------------- > > Key: ISPN-3306 > URL: https://issues.jboss.org/browse/ISPN-3306 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.Final > Reporter: Pedro Ruivo > Assignee: Mircea Markus > Fix For: 6.0.0.Final > > Attachments: RehashWithSharedCacheStoreTest.testRehashes.tar.gz > > > {code:java} > java.lang.RuntimeException: Timed out waiting for rebalancing to complete on node RehashWithSharedCacheStoreTest-NodeB-2392, current topology is CacheTopology{id=8, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[RehashWithSharedCacheStoreTest-NodeB-2392, RehashWithSharedCacheStoreTest-NodeC-18606]}, pendingCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[RehashWithSharedCacheStoreTest-NodeB-2392, RehashWithSharedCacheStoreTest-NodeC-18606]}} > at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:181) > at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:191) > at org.infinispan.distribution.rehash.RehashWithSharedCacheStoreTest.testRehashes(RehashWithSharedCacheStoreTest.java:76) > ... > {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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2203) Test AsyncAPITest.testAsyncMethodWithLifespanAndMaxIdle is unstable

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2203?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-2203: ------------------------------ Attachment: AsyncAPITest.testAsyncMethodWithLifespanAndMaxIdle.tar.gz attached trace logs... > Test AsyncAPITest.testAsyncMethodWithLifespanAndMaxIdle is unstable > ------------------------------------------------------------------- > > Key: ISPN-2203 > URL: https://issues.jboss.org/browse/ISPN-2203 > Project: Infinispan > Issue Type: Bug > Reporter: Galder Zamarreño > Assignee: Tomas Sykora > Fix For: 5.2.0.Beta2, 5.3.0.Beta2 > > Attachments: AsyncAPITest.testAsyncMethodWithLifespanAndMaxIdle.tar.gz, testAsyncMethodWithLifespanAndMaxIdle-0.log > > > Test being disabled as part of ISPN-2196 cos it's unstable. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2203) Test AsyncAPITest.testAsyncMethodWithLifespanAndMaxIdle is unstable

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2203?page=com.atlassian.jira.plugin.... ] Pedro Ruivo reopened ISPN-2203: ------------------------------- The test is still failing randomly. > Test AsyncAPITest.testAsyncMethodWithLifespanAndMaxIdle is unstable > ------------------------------------------------------------------- > > Key: ISPN-2203 > URL: https://issues.jboss.org/browse/ISPN-2203 > Project: Infinispan > Issue Type: Bug > Reporter: Galder Zamarreño > Assignee: Tomas Sykora > Fix For: 5.2.0.Beta2, 5.3.0.Beta2 > > Attachments: testAsyncMethodWithLifespanAndMaxIdle-0.log > > > Test being disabled as part of ISPN-2196 cos it's unstable. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3305) LockReorderingTest.testMixed fails randomly

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3305?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3305: ------------------------------ Attachment: LockReorderingTest.testMixed.tar.gz contains trace logs for the Replicated and Distributed version. > LockReorderingTest.testMixed fails randomly > ------------------------------------------- > > Key: ISPN-3305 > URL: https://issues.jboss.org/browse/ISPN-3305 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.Final > Reporter: Pedro Ruivo > Assignee: Mircea Markus > Fix For: 6.0.0.Final > > Attachments: LockReorderingTest.testMixed.tar.gz > > > both ReplicatedLockReorderingTest and DistLockReorderingTest are failing randomly. > ReplicatedLockReorderingTest: > http://ci.infinispan.org/viewLog.html?buildId=2196&tab=buildResultsDiv&bu... > DistLockReorderingTest: > http://ci.infinispan.org/viewLog.html?buildId=1063&tab=buildResultsDiv&bu... > {code:java} > java.lang.AssertionError > at org.infinispan.tx.lockreordering.LocalLockReorderingTest.runTest(LocalLockReorderingTest.java:66) > at org.infinispan.tx.lockreordering.DistLockReorderingTest.testMixed(DistLockReorderingTest.java:62) > ... > {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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3305) LockReorderingTest.testMixed fails randomly

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-3305: --------------------------------- Summary: LockReorderingTest.testMixed fails randomly Key: ISPN-3305 URL: https://issues.jboss.org/browse/ISPN-3305 Project: Infinispan Issue Type: Bug Affects Versions: 5.3.0.Final Reporter: Pedro Ruivo Assignee: Mircea Markus Fix For: 6.0.0.Final Attachments: LockReorderingTest.testMixed.tar.gz both ReplicatedLockReorderingTest and DistLockReorderingTest are failing randomly. ReplicatedLockReorderingTest: http://ci.infinispan.org/viewLog.html?buildId=2196&tab=buildResultsDiv&bu... DistLockReorderingTest: http://ci.infinispan.org/viewLog.html?buildId=1063&tab=buildResultsDiv&bu... {code:java} java.lang.AssertionError at org.infinispan.tx.lockreordering.LocalLockReorderingTest.runTest(LocalLockReorderingTest.java:66) at org.infinispan.tx.lockreordering.DistLockReorderingTest.testMixed(DistLockReorderingTest.java:62) ... {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

12 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2013