[JBoss JIRA] (ISPN-3527) Transaction boundary commands can be completed before state transfer applies an active transaction
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3527?page=com.atlassian.jira.plugin.... ]
Dan Berindei reassigned ISPN-3527:
----------------------------------
Assignee: Dan Berindei (was: Mircea Markus)
> Transaction boundary commands can be completed before state transfer applies an active transaction
> --------------------------------------------------------------------------------------------------
>
> Key: ISPN-3527
> URL: https://issues.jboss.org/browse/ISPN-3527
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.7.Final
> Reporter: Erik Salter
> Assignee: Dan Berindei
> Fix For: 6.0.0.Beta2, 6.0.0.Final
>
>
> There is a condition where a transaction boundary command, like a RollbackCommand, can be processed by the new owner of a tx-encapsulated key before it applies the active transaction.
> On a view change:
> The forwarding node waits until its transactions from the new topology ID is set before issuing the command.
> 2013-09-17 14:28:33,725 TRACE [org.infinispan.interceptors.InvocationContextInterceptor] (OOB-350,session-resource-cluster,east-dht5-60816(CMC-Denver-CO)) Invoked with command RollbackCommand {gtx=GlobalTransaction:<east-dht5-60816(CMC-Denver-CO)>:48002:local, cacheName='eigAllocation', topologyId=-1} and InvocationContext [org.infinispan.context.impl.LocalTxInvocationContext@1f225e51]
> 2013-09-17 14:28:33,727 TRACE [org.infinispan.statetransfer.StateTransferInterceptor] (OOB-350,session-resource-cluster,east-dht5-60816(CMC-Denver-CO)) handleTopologyAffectedCommand for command RollbackCommand {gtx=GlobalTransaction:<east-dht5-60816(CMC-Denver-CO)>:48002:local, cacheName='eigAllocation', topologyId=-1}
> 2013-09-17 14:28:33,727 TRACE [org.infinispan.statetransfer.StateTransferLockImpl] (OOB-350,session-resource-cluster,east-dht5-60816(CMC-Denver-CO)) Waiting for transaction data for topology 26, current topology is 25
> ...
> 2013-09-17 14:28:34,101 TRACE [org.infinispan.remoting.rpc.RpcManagerImpl] (OOB-350,session-resource-cluster,east-dht5-60816(CMC-Denver-CO)) east-dht5-60816(CMC-Denver-CO) broadcasting call RollbackCommand {gtx=GlobalTransaction:<east-dht5-60816(CMC-Denver-CO)>:48002:local, cacheName='eigAllocation', topologyId=26} to recipient list [west-dht4-48045(CH2-Chicago-IL), east-dht5-60816(CMC-Denver-CO), east-dht2-60243(CMC-Denver-CO)]
> However, the receiving node has not finished applying the transactions from the forwarding node yet for this topology ID. So the tx cannot be found, resulting in a stale tx and an unusable key.
> 2013-09-17 14:28:34,116 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (OOB-153,session-resource-cluster,west-dht4-48045(CH2-Chicago-IL)) Calling perform() on RollbackCommand {gtx=GlobalTransaction:<east-dht5-60816(CMC-Denver-CO)>:48002:remote, cacheName='eigAllocation', topologyId=26}
> 2013-09-17 14:28:34,116 TRACE [org.infinispan.commands.tx.AbstractTransactionBoundaryCommand] (OOB-153,session-resource-cluster,west-dht4-48045(CH2-Chicago-IL)) Did not find a RemoteTransaction for GlobalTransaction:<east-dht5-60816(CMC-Denver-CO)>:48002:remote
> 2013-09-17 14:28:34,116 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (OOB-153,session-resource-cluster,west-dht4-48045(CH2-Chicago-IL)) About to send back response SuccessfulResponse{responseValue=null} for command RollbackCommand {gtx=GlobalTransaction:<east-dht5-60816(CMC-Denver-CO)>:48002:remote, cacheName='eigAllocation', topologyId=26}
> ...
> 2013-09-17 14:28:34,161 TRACE [org.infinispan.transaction.TransactionTable] (OOB-408,session-resource-cluster,west-dht4-48045(CH2-Chicago-IL)) Created and registered remote transaction RemoteTransaction{modifications=[PutKeyValueCommand{key=EdgeResourceCacheKey[edgeDeviceId=4109,resourceId=16825], value=EdgeInputResource [edgeInputId=16825, currentBandwidth=0, maxBandwidth=1048576000], flags=null, putIfAbsent=false, lifespanMillis=-1, maxIdleTimeMillis=-1, successful=true, ignorePreviousValue=false}], lookedUpEntries={}, lockedKeys=null, backupKeyLocks=null, missingLookedUpEntries=false, isMarkedForRollback=false, tx=GlobalTransaction:<east-dht5-60816(CMC-Denver-CO)>:48002:remote}
> 2013-09-17 14:28:34,733 TRACE [org.infinispan.statetransfer.StateTransferLockImpl] (OOB-408,session-resource-cluster,west-dht4-48045(CH2-Chicago-IL)) Signalling transaction data received for topology 26
--
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, 3 months
[JBoss JIRA] (ISPN-3037) Failing test: MixedModeTest.testMixedMode:72 NullPointer
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3037?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3037:
--------------------------------
Fix Version/s: 6.0.0.Final
(was: 6.0.0.Beta2)
> Failing test: MixedModeTest.testMixedMode:72 NullPointer
> --------------------------------------------------------
>
> Key: ISPN-3037
> URL: https://issues.jboss.org/browse/ISPN-3037
> Project: Infinispan
> Issue Type: Bug
> Reporter: Sanne Grinovero
> Assignee: Pedro Ruivo
> Labels: testsuite_stability
> Fix For: 6.0.0.Final
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~ ENVIRONMENT INFO ~~~~~~~~~~~~~~~~~~~~~~~~~~
> jgroups.bind_addr = 127.0.0.1
> java.runtime.version = 1.6.0_43-b01
> java.runtime.name =Java(TM) SE Runtime Environment
> java.vm.version = 20.14-b01
> java.vm.vendor = Sun Microsystems Inc.
> os.name = Linux
> os.version = 3.8.8-202.fc18.x86_64
> sun.arch.data.model = 64
> sun.cpu.endian = little
> protocol.stack = null
> infinispan.test.jgroups.protocol = tcp
> infinispan.unsafe.allow_jdk8_chm = true
> java.net.preferIPv4Stack = true
> java.net.preferIPv6Stack = null
> log4.configuration = null
> MAVEN_OPTS = null
> ~~~~~~~~~~~~~~~~~~~~~~~~~ ENVIRONMENT INFO ~~~~~~~~~~~~~~~~~~~~~~~~~~
> Tests run: 2911, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 212.448 sec <<< FAILURE!
> testMixedMode(org.infinispan.api.MixedModeTest) Time elapsed: 0.03 sec <<< FAILURE!
> java.lang.NullPointerException
> at org.infinispan.api.MixedModeTest.testMixedMode(MixedModeTest.java:72)
> 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:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> 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:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662)
> Results :
> Failed tests:
> MixedModeTest.testMixedMode:72 NullPointer
> Tests run: 2911, Failures: 1, Errors: 0, Skipped: 0
--
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, 3 months
[JBoss JIRA] (ISPN-604) Re-design CacheStore transactions
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-604?page=com.atlassian.jira.plugin.s... ]
Mircea Markus resolved ISPN-604.
--------------------------------
Resolution: Done
The decision was made not to propagate tx context information to the cache stores, but all the locking tx might need to be handled within infinispan.
> Re-design CacheStore transactions
> ----------------------------------
>
> Key: ISPN-604
> URL: https://issues.jboss.org/browse/ISPN-604
> Project: Infinispan
> Issue Type: Sub-task
> Components: Loaders and Stores, Transactions
> Affects Versions: 4.0.0.Final, 4.1.0.CR2
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Labels: as7-ignored, modshape
> Fix For: 6.0.0.Beta2, 6.0.0.CR1
>
>
> Current(4.1.x) transaction implementation in CacheStores is brocken in several ways:
> 1st problem.
> {code}AbstractCacheStore.prepare:
> public void prepare(List<? extends Modification> mods, GlobalTransaction tx, boolean isOnePhase) throws CacheLoaderException {
> if (isOnePhase) {
> applyModifications(mods);
> } else {
> transactions.put(tx, mods);
> }
> }
> {code}
> If this is 1PC we apply the modifications in the prepare phase - we should do it in the commit phase (as JTA does it).
> 2nd problem.
> This currently exhibits during commit/rollback with JdbcXyzCacheStore, but it is rather a more general cache store issue.
> When using a TransactionManager, during TM.commit AbstractCacheStore.commit is being called internally which tries to apply all the modifications that happened during that transaction.
> Within the scope of AbstractCacheStore.commit, JdbcStore obtains a connection from a DataSource and tries to write the modifications on that connection.
> Now if the DataSource is managed (e.g. by an A.S.) on the DS.getConnection call the A.S. would try to enlist the connection with the ongoing transaction by calling Transaction.enlistResource(XAResource xaRes) [1]
> This method fails with an IllegalStateException, because the transaction's status is preparing (see javax.transaction.Transaction.enlistResource).
> Suggested fix:
> - the modifications should be registered to the transaction as they happen(vs. during prepare/commit as it happens now)
> - this requires API changes in CacheStore, e.g.
> void store(InternalCacheEntry entry)
> should become
> void store(InternalCacheEntry entry, GlobalTransaction gtx)
> (gtx would be null if this is not a transactional call).
> [1] This behavior is specified by the JDBC 2.0 Standard Extension API, chapter 7 - distributed transaction
--
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, 3 months