[JBoss JIRA] (ISPN-2727) Transactional put failed after master node with enabled InfinispanIndexManager is killed
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2727?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-2727:
-----------------------------------
Assignee: Sanne Grinovero (was: Galder Zamarreño)
> Transactional put failed after master node with enabled InfinispanIndexManager is killed
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-2727
> URL: https://issues.jboss.org/browse/ISPN-2727
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Reporter: Anna Manukyan
> Assignee: Sanne Grinovero
> Labels: stable_embedded_query
> Fix For: 5.3.0.CR1
>
> Attachments: MultiNodeDistributedTest.java, MultiNodeLocalTest.java, MultiNodeLocalTxTest.java, MultiNodeReplicatedTest.java, MultiNodeReplicatedTxTest.java
>
>
> I've added new test, which uses the following Infinispan configuration: REPL_SYNC clustering mode, with transaction enabled, as well as enabled indexing with InfinispanIndexManager.
> The test adds several nodes with the described configuration, adds entries to different nodes, and checks that the query for the entries returns the same result for all nodes.
> Then master node is killed, and then again new data is inserted and checked on all nodes. (Similiar test to https://github.com/infinispan/infinispan/blob/master/query/src/test/java/... but with enabled transaction).
> When the test tries to insert new entry to one of the caches, after the master node kill, the following exception appears:
> {code}
> testIndexingWorkDistribution(org.infinispan.query.distributed.MultiNodeReplicatedTxTest) Time elapsed: 1.656 sec <<< FAILURE!
> javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1177)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:117)
> at org.infinispan.query.distributed.MultiNodeDistributedTest.storeOn(MultiNodeDistributedTest.java:78)
> at org.infinispan.query.distributed.MultiNodeDistributedTest.testIndexingWorkDistribution(MultiNodeDistributedTest.java:102)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: org.infinispan.CacheException: Could not prepare.
> at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:70)
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:164)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165)
> ... 24 more
> Caused by: javax.transaction.xa.XAException
> at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:161)
> at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:123)
> at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68)
> ... 29 more
> {code}
> You can find the test attached. The test which fails is MultiNodeReplicatedTxTest.java . The rest are the tests which are the parents and a bit modified compared to the version in infinispan repo.
--
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 years, 5 months
[JBoss JIRA] (ISPN-2727) Transactional put failed after master node with enabled InfinispanIndexManager is killed
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2727?page=com.atlassian.jira.plugin.... ]
Work on ISPN-2727 stopped by Galder Zamarreño.
> Transactional put failed after master node with enabled InfinispanIndexManager is killed
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-2727
> URL: https://issues.jboss.org/browse/ISPN-2727
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Reporter: Anna Manukyan
> Assignee: Galder Zamarreño
> Labels: stable_embedded_query
> Fix For: 5.3.0.CR1
>
> Attachments: MultiNodeDistributedTest.java, MultiNodeLocalTest.java, MultiNodeLocalTxTest.java, MultiNodeReplicatedTest.java, MultiNodeReplicatedTxTest.java
>
>
> I've added new test, which uses the following Infinispan configuration: REPL_SYNC clustering mode, with transaction enabled, as well as enabled indexing with InfinispanIndexManager.
> The test adds several nodes with the described configuration, adds entries to different nodes, and checks that the query for the entries returns the same result for all nodes.
> Then master node is killed, and then again new data is inserted and checked on all nodes. (Similiar test to https://github.com/infinispan/infinispan/blob/master/query/src/test/java/... but with enabled transaction).
> When the test tries to insert new entry to one of the caches, after the master node kill, the following exception appears:
> {code}
> testIndexingWorkDistribution(org.infinispan.query.distributed.MultiNodeReplicatedTxTest) Time elapsed: 1.656 sec <<< FAILURE!
> javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1177)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:117)
> at org.infinispan.query.distributed.MultiNodeDistributedTest.storeOn(MultiNodeDistributedTest.java:78)
> at org.infinispan.query.distributed.MultiNodeDistributedTest.testIndexingWorkDistribution(MultiNodeDistributedTest.java:102)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: org.infinispan.CacheException: Could not prepare.
> at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:70)
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:164)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165)
> ... 24 more
> Caused by: javax.transaction.xa.XAException
> at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:161)
> at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:123)
> at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68)
> ... 29 more
> {code}
> You can find the test attached. The test which fails is MultiNodeReplicatedTxTest.java . The rest are the tests which are the parents and a bit modified compared to the version in infinispan repo.
--
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 years, 5 months
[JBoss JIRA] (ISPN-3108) Server endpoint compatibility enhancements
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3108?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3108:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1828
> Server endpoint compatibility enhancements
> ------------------------------------------
>
> Key: ISPN-3108
> URL: https://issues.jboss.org/browse/ISPN-3108
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 5.3.0.Final
>
>
> Several TODOs:
> - Transaction's lookedUpEntries, affected and lockedKeys should use equivalent collections
> - -Change equivalent hash set to be based on JSR-166- <- done in https://github.com/infinispan/infinispan/commit/c714c7785a302cb228bc8f293...
> - -Make CollectionFactory a per cache component and contain references to key/value equivalence- <- deleted since it complicates the code and does not really add value
> - figure out a way to have comparable ByteArrayEquivalence implementation and uncomment tests
> - -MetadataMortalCacheValue should extend MortalCacheValue, check others- <- That should not be the case because MetadataMortalCacheValue has metadata (which contains lifespan), and extending MortalCacheValue would add lifespan too, as separate reference, so MetadataMortalCacheValue extending MortalCacheValue would add an extra field to the object without any real benefit.
> - EntryFactoryImpl.extractMetadata: "this is invoked from wrapEntryForPut and wrapEntryForReplace. Better make these two methods receive the metadata object directly from the caller, which is aware of these commands being MetadataAwareCommand, in order to avoid the not-so-nice instanceOf."
> - Have `Builder lifespan(long time);` in Metadata builder interface and same for maxIdle.
> - The simple cache.put(k,v) (and all other non-metadata bearing methods) create an immutable metadata object that always has the same (default) values for idle and expiry. This can be an single object instance instead of creating one per operation.
--
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 years, 5 months
[JBoss JIRA] (ISPN-2695) ConcurrentNonOverlappingLeaveTest.testTransactional failing randomly
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2695?page=com.atlassian.jira.plugin.... ]
Dan Berindei resolved ISPN-2695.
--------------------------------
Resolution: Done
Looks like a duplicate of ISPN-2620.
Although this issue was created after ISPN-2620 was marked resolved, the log does show the same segment 38 appearing in two InboundTransferTasks.
> ConcurrentNonOverlappingLeaveTest.testTransactional failing randomly
> --------------------------------------------------------------------
>
> Key: ISPN-2695
> URL: https://issues.jboss.org/browse/ISPN-2695
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Reporter: Galder Zamarreño
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 5.3.0.Final
>
>
> Fails with:
> {code}testTransactional(org.infinispan.distribution.rehash.ConcurrentNonOverlappingLeaveTest) Time elapsed: 0.063 sec <<< FAILURE!
> java.lang.RuntimeException: Timed out waiting for rebalancing to complete on node ConcurrentNonOverlappingLeaveTest-NodeE-36531, current topology is CacheTopology{id=9, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[ConcurrentNonOverlappingLeaveTest-NodeE-36531, ConcurrentNonOverlappingLeaveTest-NodeG-51914], owners={0: 0 1, 1: 0, 2: 0 1, 3: 0, 4: 0 1, 5: 0, 6: 0 1, 7: 0, 8: 0 1, 9: 0, 10: 0 1, 11: 0 1, 12: 0 1, 13: 0 1, 14: 0 1, 15: 0, 16: 0, 17: 0, 18: 0, 19: 0, 20: 1 0, 21: 1 0, 22: 1 0, 23: 1 0, 24: 1 0, 25: 1 0, 26: 1 0, 27: 1 0, 28: 1 0, 29: 0 1, 30: 0, 31: 0, 32: 0, 33: 0, 34: 0, 35: 0, 36: 1, 37: 0, 38: 1, 39: 0, 40: 1, 41: 1, 42: 1, 43: 1, 44: 1, 45: 1, 46: 0, 47: 1, 48: 0, 49: 1, 50: 1, 51: 1, 52: 1, 53: 1, 54: 1, 55: 1, 56: 1, 57: 1, 58: 1, 59: 1}, pendingCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[ConcurrentNonOverlappingLeaveTest-NodeE-36531, ConcurrentNonOverlappingLeaveTest-NodeG-51914], owners={0: 0 1, 1: 0 1, 2: 0 1, 3: 0 1, 4: 0 1, 5: 0 1, 6: 0 1, 7: 0 1, 8: 0 1, 9: 0 1, 10: 0 1, 11: 0 1, 12: 0 1, 13: 0 1, 14: 0 1, 15: 0 1, 16: 0 1, 17: 0 1, 18: 0 1, 19: 0 1, 20: 1 0, 21: 1 0, 22: 1 0, 23: 1 0, 24: 1 0, 25: 1 0, 26: 1 0, 27: 1 0, 28: 1 0, 29: 0 1, 30: 0 1, 31: 0 1, 32: 0 1, 33: 0 1, 34: 0 1, 35: 0 1, 36: 1 0, 37: 0 1, 38: 1 0, 39: 0 1, 40: 1 0, 41: 1 0, 42: 1 0, 43: 1 0, 44: 1 0, 45: 1 0, 46: 0 1, 47: 1 0, 48: 0 1, 49: 1 0, 50: 1 0, 51: 1 0, 52: 1 0, 53: 1 0, 54: 1 0, 55: 1 0, 56: 1 0, 57: 1 0, 58: 1 0, 59: 1 0}}
> at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:203)
> at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:213)
> at org.infinispan.distribution.rehash.RehashLeaveTestBase.waitForRehashCompletion(RehashLeaveTestBase.java:30)
> at org.infinispan.distribution.rehash.RehashTestBase.testTransactional(RehashTestBase.java:156)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:680){code}
> TRACE log: https://dl.dropbox.com/u/6148072/testTransactional-1.tgz
--
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 years, 5 months
[JBoss JIRA] (ISPN-3120) StateConsumerImpl can ignore state received during a rebalance
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-3120?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-3120:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1826
> StateConsumerImpl can ignore state received during a rebalance
> --------------------------------------------------------------
>
> Key: ISPN-3120
> URL: https://issues.jboss.org/browse/ISPN-3120
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.6.Final, 5.3.0.Beta1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 5.3.0.CR1
>
>
> This causes random failures in ConcurrentOverlappingLeaveTest and ConcurrentNonOverlappingLeaveTest.
> 1. Starting with a 4-node cluster: [E, F, G, H] (topology 7).
> 2. F leaves, and E sends a REBALANCE_START command with nodes [E, G, H] (topology 8). Some segments are owned by [H] in the current CH and by [H, G] in the pending CH.
> 3. E reports that it finished receiving state with a REBAlANCE_CONFIRM command.
> 4. H leaves, and E sends a CH_UPDATE command with nodes [E, G] (topology 9).
> The segments that were owned by [H] in the previous currentCH are assigned to [E, G] in the new currentCH (otherwise they wouldn't have any owners).
> 5. The StateConsumerImpl on E requests state for the "lost" segments from G.
> 6. G confirms the end of the rebalance as well, and E sends a CH_UPDATE command to end the rebalance (topology 10).
> 7. E sends a REBALANCE_START command to assign all segments for [E, G] (topology 11).
> 8. While the StateConsumerImpl on E is starting the state transfer, it also receives a StateResponseCommand for the lost segments from G.
> 9. Because the structures keeping track of the received state are not properly initialized, E considers it finished receiving state for topology 11.
> 10. E receives a StateResponseCommand from G with actual data, but it ignores it because {{StateConsumerImpl.updatedKeys == null}}.
> {noformat}
> 11:30:39,807 DEBUG (transport-thread-4,NodeE:dist) [LocalTopologyManagerImpl] Updating local consistent hash(es) for cache dist: new topology = CacheTopology{id=7, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeE-51027, NodeG-6339, NodeH-47370]}, pendingCH=null}
> 11:30:39,810 DEBUG (transport-thread-3,NodeE:dist) [LocalTopologyManagerImpl] Starting local rebalance for cache dist, topology = CacheTopology{id=8, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeE-51027, NodeG-6339, NodeH-47370]}, pendingCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeE-51027, NodeG-6339, NodeH-47370]}}
> 11:30:39,817 DEBUG (transport-thread-3,NodeE:dist) [StateConsumerImpl] Finished receiving of segments for cache dist for topology 8.
> 11:30:39,832 DEBUG (transport-thread-4,NodeE:dist) [LocalTopologyManagerImpl] Updating local consistent hash(es) for cache dist: new topology = CacheTopology{id=9, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeE-51027, NodeG-6339]}, pendingCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeE-51027, NodeG-6339]}}
> 11:30:39,834 DEBUG (transport-thread-4,NodeE:dist) [StateConsumerImpl] Adding inbound state transfer for segments [38, 36, 47, 44, 45] of cache dist
> 11:30:39,853 DEBUG (transport-thread-3,NodeE:dist) [LocalTopologyManagerImpl] Starting local rebalance for cache dist, topology = CacheTopology{id=11, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeE-51027, NodeG-6339]}, pendingCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeE-51027, NodeG-6339]}}
> 11:30:39,859 TRACE (remote-thread-1,NodeE:) [InboundInvocationHandlerImpl] Calling perform() on StateResponseCommand{cache=dist, origin=NodeG-6339, topologyId=9}
> 11:30:39,864 DEBUG (remote-thread-1,NodeE:dist) [StateConsumerImpl] Finished receiving of segments for cache dist for topology 11.
> 11:30:39,866 TRACE (transport-thread-5,NodeE:dist) [LocalTopologyManagerImpl] Ignoring consistent hash update 10 for cache dist, we have already received a newer topology 11
> 11:30:39,868 TRACE (remote-thread-1,NodeE:) [InboundInvocationHandlerImpl] Calling perform() on StateResponseCommand{cache=dist, origin=NodeG-6339, topologyId=11}
> 11:30:39,872 TRACE (remote-thread-1,NodeE:dist dist) [EntryWrappingInterceptor] State transfer will not write key/value MagicKey#k3{672f69c9@NodeG-6339}/v3 because it was already updated by somebody else
> 11:30:40,582 ERROR (testng-ConcurrentNonOverlappingLeaveTest:) [UnitTestTestNGListener] Test testTransactional(org.infinispan.distribution.rehash.ConcurrentNonOverlappingLeaveTest) failed.
> java.lang.AssertionError: Fail on owner cache NodeE-51027: dc.get(MagicKey#k3{672f69c9@NodeG-6339}) returned null!
> {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
11 years, 5 months