[JBoss JIRA] (ISPN-4176) Forcing a commit via recovery RecoveryAdminOperations may create a duplicate GlobalTransaction
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-4176?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-4176:
------------------------------
Fix Version/s: 7.0.0.Beta1
(was: 7.0.0.Alpha4)
> Forcing a commit via recovery RecoveryAdminOperations may create a duplicate GlobalTransaction
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-4176
> URL: https://issues.jboss.org/browse/ISPN-4176
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Transactions
> Affects Versions: 6.0.2.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 7.0.0.Beta1
>
>
> {{RecoveryManagerImpl.forceTransactionCompletion()}} modifies the {{GlobalTransaction.address}} of the transaction being committed so that the local node is the originator. But the {{GlobalTransaction.id}} stays the same, we could have two transactions with the same {{GlobalTransaction}} - which shouldn't be possible.
> We can't remove the code that changes the {{GlobalTransaction.address}}, because we use it as the originator in other parts of the code. So the only option is to generate a new id as well.
> But there is another problem: RecoveryAwareTransactionTable.cleanupStaleTransactions() doesn't release the locks acquired by that transaction on the primary node. So forcing a commit with a different GlobalTransaction will not be able to acquire the locks that were held by the original transaction.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4167) DummyBaseTransactionManager doesn't clean up when rollback fails
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-4167?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-4167:
------------------------------
Fix Version/s: 7.0.0.Beta1
(was: 7.0.0.Alpha4)
> DummyBaseTransactionManager doesn't clean up when rollback fails
> ----------------------------------------------------------------
>
> Key: ISPN-4167
> URL: https://issues.jboss.org/browse/ISPN-4167
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.2.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 7.0.0.Beta1
>
>
> If the rollback fails, the thread local holding the current transaction is not cleared, and it becomes impossible to start a new transaction on the same thread.
> One way this can happen is when Infinispan registers as a XA transaction, but DummyTransactionManager is not configured to use XA Xids:
> {noformat}
> 12:47:57,169 ERROR (testng-ReplicationExceptionTest:) [DummyTransaction] ISPN000098: Exception while rollback
> java.lang.UnsupportedOperationException
> at org.infinispan.transaction.tm.DummyNoXaXid.getBranchQualifier(DummyNoXaXid.java:30)
> at org.infinispan.transaction.xa.recovery.SerializableXid.<init>(SerializableXid.java:37)
> at org.infinispan.transaction.xa.TransactionXaAdapter.convertXid(TransactionXaAdapter.java:251)
> at org.infinispan.transaction.xa.TransactionXaAdapter.rollback(TransactionXaAdapter.java:122)
> at org.infinispan.transaction.tm.DummyTransaction.runRollback(DummyTransaction.java:281)
> at org.infinispan.transaction.tm.DummyTransaction.rollback(DummyTransaction.java:88)
> at org.infinispan.transaction.tm.DummyBaseTransactionManager.rollback(DummyBaseTransactionManager.java:104)
> at org.infinispan.CacheImpl.tryRollback(CacheImpl.java:1442)
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1418)
> at org.infinispan.CacheImpl.putInternal(CacheImpl.java:894)
> at org.infinispan.CacheImpl.put(CacheImpl.java:886)
> at org.infinispan.CacheImpl.put(CacheImpl.java:1461)
> at org.infinispan.CacheImpl.put(CacheImpl.java:225)
> at org.infinispan.tx.synchronisation.ReplicationExceptionTest.testSyncReplTimeout(ReplicationExceptionTest.java:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4190) Use Message.Flag.DONT_LOOPBACK instead of RequestOptions.setExclusionList
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-4190?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-4190:
------------------------------
Fix Version/s: 7.0.0.Beta1
(was: 7.0.0.Alpha4)
> Use Message.Flag.DONT_LOOPBACK instead of RequestOptions.setExclusionList
> -------------------------------------------------------------------------
>
> Key: ISPN-4190
> URL: https://issues.jboss.org/browse/ISPN-4190
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 7.0.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 7.0.0.Beta1
>
>
> We are currently using {{RequestOptions.setExclusionList(channel.getAddress())}} in CommandAwareRpcDispatcher, to prevent the sender of an RPC to receive that message. We can't use {{Channel.setDiscardOwnMessages(true)}}, because TO requires messages to be delivered to self.
> JGroups 3.5.0.Beta2 has added a {{DONT_LOOPBACK}} flag, which should be a lot more efficient than using the exclusion list. We should start using it.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4193) StateSequencer: state machine-based utility for synchronizing multi-threaded tests
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-4193?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-4193:
------------------------------
Fix Version/s: 7.0.0.Beta1
(was: 7.0.0.Alpha4)
> StateSequencer: state machine-based utility for synchronizing multi-threaded tests
> ----------------------------------------------------------------------------------
>
> Key: ISPN-4193
> URL: https://issues.jboss.org/browse/ISPN-4193
> Project: Infinispan
> Issue Type: Feature Request
> Components: Test Suite - Core
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 7.0.0.Beta1
>
>
> I've previously written a {{CheckPoint}} class for the same purpose, but while the logs are a little clearer, it's still pretty hard to reason about the expected ordering of events with a CheckPoint-based test.
> StateSequencer-based tests should make it clear what the expected order of states should be from the beginning of the test:
> {code:java}
> sequencer.logicalThread("t1", "t1:block", "t1:resume");
> sequencer.logicalThread("t2", "t2:do_stuff");
> sequencer.order("t1:block", "t2:do_stuff", "t1:resume");
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months