June 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7820) Document store-by-reference effects in functional commands

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7820?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7820: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.1.0.CR1 Resolution: Done > Document store-by-reference effects in functional commands > ---------------------------------------------------------- > > Key: ISPN-7820 > URL: https://issues.jboss.org/browse/ISPN-7820 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core, Transactions > Affects Versions: 9.0.0.Final > Reporter: Radim Vansa > Assignee: Radim Vansa > Fix For: 9.1.0.CR1 > > > In transactional mode, functional read write command loads the value into the context without making a defensive copy. Then, the function is applied directly on that value, exposing uncommitted changes to all other threads. Rollback is ineffective, the value is already changed. > There are no tests for rollback in FunctionalTxInMemoryTest. > Reproducer: > {code:java} > @Test > public void testValueInContextIsACopy() throws Exception { > Object key = getKeyForCache(cache(0, DIST), cache(1, DIST)); > cache(0, DIST).put(key, new ArrayList()); > tm.begin(); > // nasty cast > FunctionalMap.ReadWriteMap<Object, List> otherRw = (FunctionalMap.ReadWriteMap) rw; > otherRw.eval(key, (Serializable & Function<EntryView.ReadWriteEntryView<Object, List>, Object>) view -> { > List list = view.get(); > list.add("woohoo"); > view.set(list); > return null; > }).join(); > tm.rollback(); > assertEquals(new ArrayList(), cache(0, DIST).get(key)); > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7993) Functional commands don't support Data convertions

by Katia Aresti (JIRA)

Katia Aresti created ISPN-7993: ---------------------------------- Summary: Functional commands don't support Data convertions Key: ISPN-7993 URL: https://issues.jboss.org/browse/ISPN-7993 Project: Infinispan Issue Type: Feature Request Components: Core Reporter: Katia Aresti Assignee: Katia Aresti Fix For: 9.2 Functional commands don't support encoding For example, in this test {code} public class ClusteredCacheTest extends MultipleCacheManagersTest { public void testFunctionalMap() throws Exception { prepareTestData(); FunctionalMapImpl functionalMap = FunctionalMapImpl.create(this.cache2.getAdvancedCache()); FunctionalMap.ReadWriteMap<String, String> readWriteMap = ReadWriteMapImpl.create(functionalMap); readWriteMap.eval("k", view -> { view.set("v"); return null; }).join(); assertEquals("v", cache2.get("k")); } } {code} Returns this exception when the StorageType is OFF_HEAP -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6997) PessimisticTxPartitionAndMergeDuringRuntimeTest.testOriginatorIsolatedPartition random failures

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6997?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-6997: -------------------------------- Fix Version/s: 9.1.0.CR1 (was: 9.1.0.Final) > PessimisticTxPartitionAndMergeDuringRuntimeTest.testOriginatorIsolatedPartition random failures > ----------------------------------------------------------------------------------------------- > > Key: ISPN-6997 > URL: https://issues.jboss.org/browse/ISPN-6997 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 9.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 9.1.0.CR1 > > > The test starts with a cluster of 4 nodes, and splits it in 2 partitions while a transaction is trying to lock a key. After the transaction fails, it checks that the transaction has been cleaned up properly. > On one of the owners, {{transactionTable.cleanupLeaverTransactions}} is being called only before the split and after the merge, never with the list of members during the split. That means it never sees the transaction as an orphan, and doesn't remove it. > {noformat} > 15:16:18,893 TRACE (testng-PTPAMDRT:[]) [PTPAMDRT] Local tx=[], remote tx=[GlobalTx:PTPAMDRT-NodeI-3337:28616], for cache PTPAMDRT-NodeJ-27814 > 15:16:18,893 ERROR (testng-PTPAMDRT:[]) [TestSuiteProgress] Test failed: org.infinispan.partitionhandling.PTPAMDRT.testOriginatorIsolatedPartition > java.lang.AssertionError: There are pending transactions! > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) ~[testng-6.8.8.jar:?] > at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:223) ~[test-classes/:?] > at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:519) ~[test-classes/:?] > at org.infinispan.test.MultipleCacheManagersTest.assertNoTransactions(MultipleCacheManagersTest.java:794) ~[test-classes/:?] > at org.infinispan.partitionhandling.BaseTxPartitionAndMergeTest.finalAsserts(BaseTxPartitionAndMergeTest.java:96) ~[test-classes/:?] > at org.infinispan.partitionhandling.BasePessimisticTxPartitionAndMergeTest.doTest(BasePessimisticTxPartitionAndMergeTest.java:82) ~[test-classes/:?] > at org.infinispan.partitionhandling.tionAndMergeDuringRuntimeTest.testOriginatorIsolatedPartition(PessimisticTxPartitionAndMergeDuringRuntimeTest.java:33) ~[test-classes/:?] > {noformat} > {{OptimisticTxPartitionAndMergeDuringCommitTest.testPrimaryOwnerIsolatedPartition}} has similar random failures. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6997) PessimisticTxPartitionAndMergeDuringRuntimeTest.testOriginatorIsolatedPartition random failures

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6997?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-6997: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > PessimisticTxPartitionAndMergeDuringRuntimeTest.testOriginatorIsolatedPartition random failures > ----------------------------------------------------------------------------------------------- > > Key: ISPN-6997 > URL: https://issues.jboss.org/browse/ISPN-6997 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 9.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 9.1.0.CR1 > > > The test starts with a cluster of 4 nodes, and splits it in 2 partitions while a transaction is trying to lock a key. After the transaction fails, it checks that the transaction has been cleaned up properly. > On one of the owners, {{transactionTable.cleanupLeaverTransactions}} is being called only before the split and after the merge, never with the list of members during the split. That means it never sees the transaction as an orphan, and doesn't remove it. > {noformat} > 15:16:18,893 TRACE (testng-PTPAMDRT:[]) [PTPAMDRT] Local tx=[], remote tx=[GlobalTx:PTPAMDRT-NodeI-3337:28616], for cache PTPAMDRT-NodeJ-27814 > 15:16:18,893 ERROR (testng-PTPAMDRT:[]) [TestSuiteProgress] Test failed: org.infinispan.partitionhandling.PTPAMDRT.testOriginatorIsolatedPartition > java.lang.AssertionError: There are pending transactions! > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) ~[testng-6.8.8.jar:?] > at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:223) ~[test-classes/:?] > at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:519) ~[test-classes/:?] > at org.infinispan.test.MultipleCacheManagersTest.assertNoTransactions(MultipleCacheManagersTest.java:794) ~[test-classes/:?] > at org.infinispan.partitionhandling.BaseTxPartitionAndMergeTest.finalAsserts(BaseTxPartitionAndMergeTest.java:96) ~[test-classes/:?] > at org.infinispan.partitionhandling.BasePessimisticTxPartitionAndMergeTest.doTest(BasePessimisticTxPartitionAndMergeTest.java:82) ~[test-classes/:?] > at org.infinispan.partitionhandling.tionAndMergeDuringRuntimeTest.testOriginatorIsolatedPartition(PessimisticTxPartitionAndMergeDuringRuntimeTest.java:33) ~[test-classes/:?] > {noformat} > {{OptimisticTxPartitionAndMergeDuringCommitTest.testPrimaryOwnerIsolatedPartition}} has similar random failures. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7960) TxInterceptor.verifyRemoteTransaction ignores partition handling

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7960?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7960: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.1.0.CR1 (was: 9.1.0.Final) Resolution: Done > TxInterceptor.verifyRemoteTransaction ignores partition handling > ---------------------------------------------------------------- > > Key: ISPN-7960 > URL: https://issues.jboss.org/browse/ISPN-7960 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.1.0.Beta1, 9.0.3.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 9.1.0.CR1 > > > https://github.com/infinispan/infinispan/pull/5143 fixes the random test failures in {{PessimisticTxPartitionAndMergeDuringRuntimeTest.testOriginatorIsolatedPartition}}, but it uncovers another random failure in {{OptimisticTxPartitionAndMergeDuringCommitTest.testDegradedPartitionWithDiscard}}. > When partition handling is enabled, {{TransactionTable.cleanupLeaverTransactions()}} will not roll back transactions from leavers, instead it will keep them in limbo until it sees a stable cache topology (i.e. either until the cache's stable topology is updated, or until all the stable topology's members are re-added to the current topology). {{TxInterceptor.verifyRemoteTransaction()}} instead always rolls back the transaction if the originator is not in the cluster view, and when the originator tries to complete the transaction after the merge it gets an exception: > {noformat} > 10:27:34,880 WARN (remote-thread-Test-NodeG-p46360-t6:[]) [NonTotalOrderTxPerCacheInboundInvocationHandler] ISPN000071: Caught exception when handling command VersionedCommitCommand{gtx=GlobalTx:Test-NodeE-10968:31983, cacheName='opt-cache', topologyId=16, updatedVersions={MagicKey#k1{168F/00552148/106@Test-NodeF-27031}=SimpleClusteredVersion{topologyId=13, version=2}, MagicKey#k2{1690/CCE79580/35@Test-NodeG-8587}=SimpleClusteredVersion{topologyId=13, version=2}}} > org.infinispan.commons.CacheException: ISPN000361: Cannot commit remote transaction GlobalTx:Test-NodeE-10968:31983 as it was already rolled back > at org.infinispan.commands.tx.CommitCommand.invalidRemoteTxReturnValue(CommitCommand.java:49) ~[classes/:?] > at org.infinispan.commands.tx.AbstractTransactionBoundaryCommand.invokeAsync(AbstractTransactionBoundaryCommand.java:98) ~[classes/:?] > {noformat} > The test splits actually tries to ensure that the {{CommitCommand}} is never executed on the owner before the split, only after the merge. But the {{DiscardFilter}} that it uses only blocks one invocation, and it lets the commit proceed when the originator retries: > {noformat} > 10:27:34,394 DEBUG (jgroups-6,Test-NodeG-8587:[]) [BaseTxPartitionAndMergeTest] Ignoring command VersionedCommitCommand{gtx=GlobalTx:Test-NodeE-10968:31983, cacheName='opt-cache', topologyId=13, updatedVersions={MagicKey#k1{168F/00552148/106@Test-NodeF-27031}=SimpleClusteredVersion{topologyId=13, version=2}, MagicKey#k2{1690/CCE79580/35@Test-NodeG-8587}=SimpleClusteredVersion{topologyId=13, version=2}}} > 10:27:34,416 DEBUG (transport-thread-Test-NodeE-p46282-t3:[Topology-opt-cache]) [LocalTopologyManagerImpl] Updating local topology for cache opt-cache: CacheTopology{id=14, rebalanceId=4, currentCH=DefaultConsistentHash{ns=256, owners = (4)[Test-NodeE-10968: 67+67, Test-NodeF-27031: 59+65, Test-NodeG-8587: 63+57, Test-NodeH-3978: 67+67]}, pendingCH=null, unionCH=null, phase=NO_REBALANCE, actualMembers=[Test-NodeE-10968, Test-NodeF-27031], persistentUUIDs=[72351dc9-f621-41df-896b-1dc2f26798f5, 61811c2f-4931-49e2-b395-4debd39f6ca1]} > 10:27:34,442 TRACE (jgroups-6,Test-NodeE-10968:[]) [RpcManagerImpl] Response(s) to VersionedCommitCommand{gtx=GlobalTx:Test-NodeE-10968:31983, cacheName='opt-cache', topologyId=13, updatedVersions={MagicKey#k1{168F/00552148/106@Test-NodeF-27031}=SimpleClusteredVersion{topologyId=13, version=2}, MagicKey#k2{1690/CCE79580/35@Test-NodeG-8587}=SimpleClusteredVersion{topologyId=13, version=2}}} is {Test-NodeG-8587=CacheNotFoundResponse, Test-NodeF-27031=SuccessfulResponse(null)} > 10:27:34,442 TRACE (jgroups-6,Test-NodeE-10968:[]) [TxDistributionInterceptor] We have a newer topology, ignoring responses and retrying > 10:27:34,451 TRACE (jgroups-6,Test-NodeE-10968:[]) [RpcManagerImpl] Test-NodeE-10968 invoking VersionedCommitCommand{gtx=GlobalTx:Test-NodeE-10968:31983, cacheName='opt-cache', topologyId=14, updatedVersions={MagicKey#k1{168F/00552148/106@Test-NodeF-27031}=SimpleClusteredVersion{topologyId=13, version=2}, MagicKey#k2{1690/CCE79580/35@Test-NodeG-8587}=SimpleClusteredVersion{topologyId=13, version=2}}} to recipient list [Test-NodeF-27031, Test-NodeG-8587] with options RpcOptions{timeout=15000, unit=MILLISECONDS, deliverOrder=NONE, responseFilter=null, responseMode=SYNCHRONOUS_IGNORE_LEAVERS} > 10:27:34,637 TRACE (remote-thread-Test-NodeG-p46360-t6:[]) [TxInterceptor] Replaying the transactions received as a result of state transfer VersionedPrepareCommand {modifications=[PutKeyValueCommand{key=MagicKey#k1{168F/00552148/106@Test-NodeF-27031}, value=final-value, flags=[], commandInvocationId=CommandInvocation:local:0, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=null}, successful=true, topologyId=13}, PutKeyValueCommand{key=MagicKey#k2{1690/CCE79580/35@Test-NodeG-8587}, value=final-value, flags=[], commandInvocationId=CommandInvocation:local:0, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=null}, successful=true, topologyId=13}], onePhaseCommit=false, retried=false, versionsSeen=null, gtx=GlobalTx:Test-NodeE-10968:31983, cacheName='opt-cache'} > 10:27:34,661 TRACE (remote-thread-Test-NodeG-p46360-t6:[]) [TxInterceptor] Rolling back remote transaction GlobalTx:Test-NodeE-10968:31983 because either already completed (false) or originator no longer in the cluster (true). > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7992) Indexing auto-config should associate a default persistent storage for indexes if the user's cache is persistent

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-7992: ----------------------------------- Summary: Indexing auto-config should associate a default persistent storage for indexes if the user's cache is persistent Key: ISPN-7992 URL: https://issues.jboss.org/browse/ISPN-7992 Project: Infinispan Issue Type: Bug Affects Versions: 9.1.0.Beta1, 8.2.7.Final, 9.0.0.Final Reporter: Adrian Nistor Assignee: Gustavo Fernandes -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7988) ScatteredSyncFuncTest>DistSyncFuncTest.testComputeIfAbsentFromNonOwner fails with trace logging enabled

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-7988?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-7988: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5246 > ScatteredSyncFuncTest>DistSyncFuncTest.testComputeIfAbsentFromNonOwner fails with trace logging enabled > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-7988 > URL: https://issues.jboss.org/browse/ISPN-7988 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Reporter: Dan Berindei > Assignee: Radim Vansa > Priority: Critical > Labels: testsuite_stability > > Every time I run the test I get this failure twice, with the same test parameters: > {noformat} > testComputeIfAbsentFromNonOwner[SCATTERED_SYNC, tx=false, numOwners=1, l1=false](org.infinispan.scattered.ScatteredSyncFuncTest) Time elapsed: 0.159 sec <<< FAILURE! > java.lang.AssertionError: expected [1] but found [0] > at org.testng.Assert.fail(Assert.java:94) > at org.testng.Assert.failNotEquals(Assert.java:494) > at org.testng.Assert.assertEquals(Assert.java:123) > at org.testng.Assert.assertEquals(Assert.java:370) > at org.testng.Assert.assertEquals(Assert.java:380) > at org.infinispan.scattered.Utils.assertOwnershipAndNonOwnership(Utils.java:49) > at org.infinispan.scattered.ScatteredSyncFuncTest.assertOwnershipAndNonOwnership(ScatteredSyncFuncTest.java:20) > at org.infinispan.distribution.BaseDistFunctionalTest.assertOnAllCachesAndOwnership(BaseDistFunctionalTest.java:162) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7991) Compatibility between Rest and HotRod not working on both ways

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-7991?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-7991: -------------------------------- Status: Open (was: New) > Compatibility between Rest and HotRod not working on both ways > -------------------------------------------------------------- > > Key: ISPN-7991 > URL: https://issues.jboss.org/browse/ISPN-7991 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 8.2.7.Final, 9.1.0.Beta1, 9.0.3.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > > Writing via Hot Rod and reading via Rest works fine, but not the other way around -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7991) Compatibility between Rest and HotRod not working on both ways

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7991?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-7991: ------------------------------------ Description: Writing via Hot Rod and reading via Rest works fine, but not the other way around (was: Writing writing via Hot Rod and reading via Rest, it works fine, but not the other way around) > Compatibility between Rest and HotRod not working on both ways > -------------------------------------------------------------- > > Key: ISPN-7991 > URL: https://issues.jboss.org/browse/ISPN-7991 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 8.2.7.Final, 9.1.0.Beta1, 9.0.3.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > > Writing via Hot Rod and reading via Rest works fine, but not the other way around -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7991) Compatibility between Rest and HotRod not working on both ways

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7991?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-7991: ------------------------------------ Affects Version/s: 9.1.0.Beta1 > Compatibility between Rest and HotRod not working on both ways > -------------------------------------------------------------- > > Key: ISPN-7991 > URL: https://issues.jboss.org/browse/ISPN-7991 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 8.2.7.Final, 9.1.0.Beta1, 9.0.3.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > > Writing writing via Hot Rod and reading via Rest, it works fine, but not the other way around -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2017