[JBoss JIRA] (ISPN-8231) InfinispanModulesStoreJdbcIT.testXmlConfig and InfinispanStoreJdbcIT.testXmlConfig random failure
by Katia Aresti (JIRA)
[ https://issues.jboss.org/browse/ISPN-8231?page=com.atlassian.jira.plugin.... ]
Work on ISPN-8231 started by Katia Aresti.
------------------------------------------
> InfinispanModulesStoreJdbcIT.testXmlConfig and InfinispanStoreJdbcIT.testXmlConfig random failure
> -------------------------------------------------------------------------------------------------
>
> Key: ISPN-8231
> URL: https://issues.jboss.org/browse/ISPN-8231
> Project: Infinispan
> Issue Type: Bug
> Reporter: Katia Aresti
> Assignee: Katia Aresti
> Labels: testsuite_stability
> Fix For: 9.1.1.Final
>
>
> org.infinispan.test.integration.as.InfinispanModulesStoreJdbcIT.testXmlConfig and
> org.infinispan.test.integration.as.InfinispanStoreJdbcIT.testXmlConfig
> conflict on JMX
> testXmlConfig
> org.infinispan.jmx.JmxDomainConflictException: ISPN000034: There's already a JMX MBean instance type=CacheManager,name="DefaultCacheManager" already registered under 'org.infinispan' JMX domain. If you want to allow multiple instances configured with same JMX domain enable 'allowDuplicateDomains' attribute in 'globalJmxStatistics' config element at org.infinispan.test.integration.as.InfinispanModulesStoreJdbcIT.testXmlConfig(InfinispanModulesStoreJdbcIT.java:57)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (ISPN-8229) Rest Server should allow custom maxContentLength
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-8229:
-------------------------------------
Summary: Rest Server should allow custom maxContentLength
Key: ISPN-8229
URL: https://issues.jboss.org/browse/ISPN-8229
Project: Infinispan
Issue Type: Bug
Components: Remote Protocols, Server
Affects Versions: 9.1.0.Final
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 9.2.0.Final
The REST endpoint and the REST cache store need to support custom maxContentLength
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (ISPN-8230) Rest Server should allow custom maxContentLength
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-8230:
-------------------------------------
Summary: Rest Server should allow custom maxContentLength
Key: ISPN-8230
URL: https://issues.jboss.org/browse/ISPN-8230
Project: Infinispan
Issue Type: Bug
Components: Remote Protocols, Server
Affects Versions: 9.1.0.Final
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 9.2.0.Final
The REST endpoint and the REST cache store need to support custom maxContentLength
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (ISPN-8228) End invalidation messages lingering from previous Hibernate Cache tests
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-8228?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-8228:
----------------------------------------
TRACE logs can be found [here|https://www.dropbox.com/s/z13yrik9n1q95yj/ISPN-8228_0824.zip?dl=0].
A summary of the supporting log lines to detect the end invalidation message leak can be found [here|https://gist.github.com/galderz/a68756aaf30d980bad00dc794f29cacb].
> End invalidation messages lingering from previous Hibernate Cache tests
> -----------------------------------------------------------------------
>
> Key: ISPN-8228
> URL: https://issues.jboss.org/browse/ISPN-8228
> Project: Infinispan
> Issue Type: Bug
> Components: Hibernate Cache
> Affects Versions: 9.1.0.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: testsuite_stability
> Fix For: 9.1.1.Final
>
>
> While trying to replicate size related failures in ISPN-8206, I've discovered some put from load calls do not always succeed, e.g.
> {code}
> [ERROR] Tests run: 144, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 20.959 s <<< FAILURE! - in org.infinispan.test.hibernate.cache.collection.CollectionRegionAccessStrategyTest
> [ERROR] testRemoveAll[Non-JTA, INVALIDATION_SYNC,AccessType[transactional]](org.infinispan.test.hibernate.cache.collection.CollectionRegionAccessStrategyTest) Time elapsed: 0.017 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at org.infinispan.test.hibernate.cache.AbstractRegionAccessStrategyTest.evictOrRemoveAllTest(AbstractRegionAccessStrategyTest.Java:557)
> at org.infinispan.test.hibernate.cache.AbstractRegionAccessStrategyTest.testRemoveAll(AbstractRegionAccessStrategyTest.java:438)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.hibernate.testing.junit4.ExtendedFrameworkMethod.invokeExplosively(ExtendedFrameworkMethod.java:45)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.infinispan.test.hibernate.cache.util.InfinispanTestingSetup$1.evaluate(InfinispanTestingSetup.java:38)
> at org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74)
> {code}
> The reason these sometimes fails is because previously running tests, e.g. testRemove, are not waiting for end invalidation message to be consumed before finishing the test. As a result of this, an end invalidation from an earlier test can be left lingering and can trigger a latch that should only be triggered by an end invalidation message within the test itself.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (ISPN-8228) End invalidation messages lingering from previous Hibernate Cache tests
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-8228?page=com.atlassian.jira.plugin.... ]
Work on ISPN-8228 started by Galder Zamarreño.
----------------------------------------------
> End invalidation messages lingering from previous Hibernate Cache tests
> -----------------------------------------------------------------------
>
> Key: ISPN-8228
> URL: https://issues.jboss.org/browse/ISPN-8228
> Project: Infinispan
> Issue Type: Bug
> Components: Hibernate Cache
> Affects Versions: 9.1.0.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: testsuite_stability
> Fix For: 9.1.1.Final
>
>
> While trying to replicate size related failures in ISPN-8206, I've discovered some put from load calls do not always succeed, e.g.
> {code}
> [ERROR] Tests run: 144, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 20.959 s <<< FAILURE! - in org.infinispan.test.hibernate.cache.collection.CollectionRegionAccessStrategyTest
> [ERROR] testRemoveAll[Non-JTA, INVALIDATION_SYNC,AccessType[transactional]](org.infinispan.test.hibernate.cache.collection.CollectionRegionAccessStrategyTest) Time elapsed: 0.017 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at org.infinispan.test.hibernate.cache.AbstractRegionAccessStrategyTest.evictOrRemoveAllTest(AbstractRegionAccessStrategyTest.Java:557)
> at org.infinispan.test.hibernate.cache.AbstractRegionAccessStrategyTest.testRemoveAll(AbstractRegionAccessStrategyTest.java:438)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.hibernate.testing.junit4.ExtendedFrameworkMethod.invokeExplosively(ExtendedFrameworkMethod.java:45)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.infinispan.test.hibernate.cache.util.InfinispanTestingSetup$1.evaluate(InfinispanTestingSetup.java:38)
> at org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74)
> {code}
> The reason these sometimes fails is because previously running tests, e.g. testRemove, are not waiting for end invalidation message to be consumed before finishing the test. As a result of this, an end invalidation from an earlier test can be left lingering and can trigger a latch that should only be triggered by an end invalidation message within the test itself.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (ISPN-8228) End invalidation messages lingering from previous Hibernate Cache tests
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-8228?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-8228:
-----------------------------------
Status: Open (was: New)
> End invalidation messages lingering from previous Hibernate Cache tests
> -----------------------------------------------------------------------
>
> Key: ISPN-8228
> URL: https://issues.jboss.org/browse/ISPN-8228
> Project: Infinispan
> Issue Type: Bug
> Components: Hibernate Cache
> Affects Versions: 9.1.0.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: testsuite_stability
> Fix For: 9.1.1.Final
>
>
> While trying to replicate size related failures in ISPN-8206, I've discovered some put from load calls do not always succeed, e.g.
> {code}
> [ERROR] Tests run: 144, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 20.959 s <<< FAILURE! - in org.infinispan.test.hibernate.cache.collection.CollectionRegionAccessStrategyTest
> [ERROR] testRemoveAll[Non-JTA, INVALIDATION_SYNC,AccessType[transactional]](org.infinispan.test.hibernate.cache.collection.CollectionRegionAccessStrategyTest) Time elapsed: 0.017 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at org.infinispan.test.hibernate.cache.AbstractRegionAccessStrategyTest.evictOrRemoveAllTest(AbstractRegionAccessStrategyTest.Java:557)
> at org.infinispan.test.hibernate.cache.AbstractRegionAccessStrategyTest.testRemoveAll(AbstractRegionAccessStrategyTest.java:438)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.hibernate.testing.junit4.ExtendedFrameworkMethod.invokeExplosively(ExtendedFrameworkMethod.java:45)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.infinispan.test.hibernate.cache.util.InfinispanTestingSetup$1.evaluate(InfinispanTestingSetup.java:38)
> at org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74)
> {code}
> The reason these sometimes fails is because previously running tests, e.g. testRemove, are not waiting for end invalidation message to be consumed before finishing the test. As a result of this, an end invalidation from an earlier test can be left lingering and can trigger a latch that should only be triggered by an end invalidation message within the test itself.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (ISPN-8228) End invalidation messages lingering from previous Hibernate Cache tests
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-8228:
--------------------------------------
Summary: End invalidation messages lingering from previous Hibernate Cache tests
Key: ISPN-8228
URL: https://issues.jboss.org/browse/ISPN-8228
Project: Infinispan
Issue Type: Bug
Components: Hibernate Cache
Affects Versions: 9.1.0.Final
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 9.1.1.Final
While trying to replicate size related failures in ISPN-8206, I've discovered some put from load calls do not always succeed, e.g.
{code}
[ERROR] Tests run: 144, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 20.959 s <<< FAILURE! - in org.infinispan.test.hibernate.cache.collection.CollectionRegionAccessStrategyTest
[ERROR] testRemoveAll[Non-JTA, INVALIDATION_SYNC,AccessType[transactional]](org.infinispan.test.hibernate.cache.collection.CollectionRegionAccessStrategyTest) Time elapsed: 0.017 s <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at org.infinispan.test.hibernate.cache.AbstractRegionAccessStrategyTest.evictOrRemoveAllTest(AbstractRegionAccessStrategyTest.Java:557)
at org.infinispan.test.hibernate.cache.AbstractRegionAccessStrategyTest.testRemoveAll(AbstractRegionAccessStrategyTest.java:438)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.hibernate.testing.junit4.ExtendedFrameworkMethod.invokeExplosively(ExtendedFrameworkMethod.java:45)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.infinispan.test.hibernate.cache.util.InfinispanTestingSetup$1.evaluate(InfinispanTestingSetup.java:38)
at org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74)
{code}
The reason these sometimes fails is because previously running tests, e.g. testRemove, are not waiting for end invalidation message to be consumed before finishing the test. As a result of this, an end invalidation from an earlier test can be left lingering and can trigger a latch that should only be triggered by an end invalidation message within the test itself.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (ISPN-8227) OptimisticTxPartitionAndMergeDuringPrepareTest.testPrimaryOwnerIsolatedPartition fails randomly
by Radim Vansa (JIRA)
Radim Vansa created ISPN-8227:
---------------------------------
Summary: OptimisticTxPartitionAndMergeDuringPrepareTest.testPrimaryOwnerIsolatedPartition fails randomly
Key: ISPN-8227
URL: https://issues.jboss.org/browse/ISPN-8227
Project: Infinispan
Issue Type: Bug
Components: Core, Test Suite - Core
Affects Versions: 9.1.0.Final
Reporter: Radim Vansa
Assignee: Radim Vansa
Attachments: log.txt
The issue seems to be that during several topology changes the originator sends 2 VersionedPrepareCommands, 1 VersionedCommitCommand and 1 TxCompletionNotificationCommand. These commands are resent after cluster merge and then executed in arbitrary order, and after the completion notification command removes tx information from {{TransactionTable}} another prepare command adds it again.
Logs attached, don't get confused by the fact that
{code}
14:54:29,056 TRACE [org.infinispan.transaction.impl.TransactionTable] (remote-thread-test-NodeC-p146-t4) Created and registered remote transaction RemoteTransaction{modifications=[PutKeyValueCommand{key=MagicKey#k1{8/537A1109/107@test-NodeB-18592}, 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{9/0AD74A7B/101@test-NodeC-10992}, 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}], lookedUpEntries={}, lockedKeys=[], backupKeyLocks=[], lookedUpEntriesTopology=2147483647, isMarkedForRollback=false, tx=GlobalTx:test-NodeA-55522:15, state=null}
{code}
appears in the log before
{code}
14:54:29,056 TRACE [org.infinispan.transaction.impl.TransactionTable] (remote-thread-test-NodeC-p146-t6) Removed remote transaction GlobalTx:test-NodeA-55522:15 ? RemoteTransaction{modifications=[PutKeyValueComm
and{key=MagicKey#k1{8/537A1109/107@test-NodeB-18592}, 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{9/0AD74A7B/101@test-NodeC-10992}, value=final-value, flags=[], commandInvocationId=CommandInvocation:lo
cal:0, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=null}, successful=true, topologyId=13}], lookedUpEntries={MagicKey#k2{9/0AD74A7B/101@test-
NodeC-10992}=VersionedRepeatableReadEntry(51ecb641){key=MagicKey#k2{9/0AD74A7B/101@test-NodeC-10992}, value=final-value, isCreated=false, isChanged=true, isRemoved=false, isExpired=false, skipLookup=true, metada
ta=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=SimpleClusteredVersion{topologyId=13, version=1}}}, MagicKey#k1{8/537A1109/107@test-NodeB-18592}=VersionedRepeatableReadEntry(7a4c1b3f){key=MagicKey#
k1{8/537A1109/107@test-NodeB-18592}, value=final-value, isCreated=false, isChanged=true, isRemoved=false, isExpired=false, skipLookup=true, metadata=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=Sim
pleClusteredVersion{topologyId=13, version=1}}}}, lockedKeys=[MagicKey#k2{9/0AD74A7B/101@test-NodeC-10992}], backupKeyLocks=[MagicKey#k1{8/537A1109/107@test-NodeB-18592}], lookedUpEntriesTopology=14, isMarkedFor
Rollback=false, tx=GlobalTx:test-NodeA-55522:15, state=null}
{code}
While we check {{TransactionTable.isTransactionCompleted()}} within {{remoteTransactions.compute}}, there is a race between calling {{TransactionTable.removeRemoteTransaction}} and {{TransactionTable.markTransactionCompleted}}. My suggestion is to mark transaction as complete from within the {{removeRemoteTransaction}} method, using {{remoteTransactions.compute}}.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (ISPN-8227) OptimisticTxPartitionAndMergeDuringPrepareTest.testPrimaryOwnerIsolatedPartition fails randomly
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-8227?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-8227:
------------------------------
Attachment: log.txt
> OptimisticTxPartitionAndMergeDuringPrepareTest.testPrimaryOwnerIsolatedPartition fails randomly
> -----------------------------------------------------------------------------------------------
>
> Key: ISPN-8227
> URL: https://issues.jboss.org/browse/ISPN-8227
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 9.1.0.Final
> Reporter: Radim Vansa
> Assignee: Radim Vansa
> Attachments: log.txt
>
>
> The issue seems to be that during several topology changes the originator sends 2 VersionedPrepareCommands, 1 VersionedCommitCommand and 1 TxCompletionNotificationCommand. These commands are resent after cluster merge and then executed in arbitrary order, and after the completion notification command removes tx information from {{TransactionTable}} another prepare command adds it again.
> Logs attached, don't get confused by the fact that
> {code}
> 14:54:29,056 TRACE [org.infinispan.transaction.impl.TransactionTable] (remote-thread-test-NodeC-p146-t4) Created and registered remote transaction RemoteTransaction{modifications=[PutKeyValueCommand{key=MagicKey#k1{8/537A1109/107@test-NodeB-18592}, 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{9/0AD74A7B/101@test-NodeC-10992}, 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}], lookedUpEntries={}, lockedKeys=[], backupKeyLocks=[], lookedUpEntriesTopology=2147483647, isMarkedForRollback=false, tx=GlobalTx:test-NodeA-55522:15, state=null}
> {code}
> appears in the log before
> {code}
> 14:54:29,056 TRACE [org.infinispan.transaction.impl.TransactionTable] (remote-thread-test-NodeC-p146-t6) Removed remote transaction GlobalTx:test-NodeA-55522:15 ? RemoteTransaction{modifications=[PutKeyValueComm
> and{key=MagicKey#k1{8/537A1109/107@test-NodeB-18592}, 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{9/0AD74A7B/101@test-NodeC-10992}, value=final-value, flags=[], commandInvocationId=CommandInvocation:lo
> cal:0, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=null}, successful=true, topologyId=13}], lookedUpEntries={MagicKey#k2{9/0AD74A7B/101@test-
> NodeC-10992}=VersionedRepeatableReadEntry(51ecb641){key=MagicKey#k2{9/0AD74A7B/101@test-NodeC-10992}, value=final-value, isCreated=false, isChanged=true, isRemoved=false, isExpired=false, skipLookup=true, metada
> ta=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=SimpleClusteredVersion{topologyId=13, version=1}}}, MagicKey#k1{8/537A1109/107@test-NodeB-18592}=VersionedRepeatableReadEntry(7a4c1b3f){key=MagicKey#
> k1{8/537A1109/107@test-NodeB-18592}, value=final-value, isCreated=false, isChanged=true, isRemoved=false, isExpired=false, skipLookup=true, metadata=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=Sim
> pleClusteredVersion{topologyId=13, version=1}}}}, lockedKeys=[MagicKey#k2{9/0AD74A7B/101@test-NodeC-10992}], backupKeyLocks=[MagicKey#k1{8/537A1109/107@test-NodeB-18592}], lookedUpEntriesTopology=14, isMarkedFor
> Rollback=false, tx=GlobalTx:test-NodeA-55522:15, state=null}
> {code}
> While we check {{TransactionTable.isTransactionCompleted()}} within {{remoteTransactions.compute}}, there is a race between calling {{TransactionTable.removeRemoteTransaction}} and {{TransactionTable.markTransactionCompleted}}. My suggestion is to mark transaction as complete from within the {{removeRemoteTransaction}} method, using {{remoteTransactions.compute}}.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months