[JBoss JIRA] (ISPN-4893) MultiNodeReplicatedTxTest.testIndexingWorkDistribution random failures
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4893?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-4893:
----------------------------------
Fix Version/s: (was: 7.1.0.CR1)
> MultiNodeReplicatedTxTest.testIndexingWorkDistribution random failures
> ----------------------------------------------------------------------
>
> Key: ISPN-4893
> URL: https://issues.jboss.org/browse/ISPN-4893
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Query
> Affects Versions: 7.0.0.CR2
> Reporter: Dan Berindei
> Priority: Blocker
> Labels: testsuite_stability
>
> The test kills the master node, waits for the default cache to rebalance, and then calls put. Still, the put fails because of a SuspectException:
> {noformat}
> 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:126)
> at org.infinispan.query.distributed.MultiNodeDistributedTest.storeOn(MultiNodeDistributedTest.java:40)
> at org.infinispan.query.distributed.MultiNodeDistributedTest.testIndexingWorkDistribution(MultiNodeDistributedTest.java:66)
> 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:606)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> 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:348)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:38)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.infinispan.commons.CacheException: Could not prepare.
> at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:46)
> 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:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165)
> ... 23 more
> Caused by: javax.transaction.xa.XAException
> at org.infinispan.transaction.impl.TransactionCoordinator.prepare(TransactionCoordinator.java:141)
> at org.infinispan.transaction.impl.TransactionCoordinator.prepare(TransactionCoordinator.java:104)
> at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:44)
> ... 28 more
> Caused by: org.infinispan.remoting.transport.jgroups.SuspectException: Suspected member: MultiNodeReplicatedTxTest-NodeA-18814
> at org.infinispan.remoting.transport.AbstractTransport.parseResponseAndAddToResponseList(AbstractTransport.java:72)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:562)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:290)
> at org.infinispan.interceptors.distribution.TxDistributionInterceptor.prepareOnAffectedNodes(TxDistributionInterceptor.java:213)
> at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitPrepareCommand(TxDistributionInterceptor.java:197)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:109)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:97)
> at org.infinispan.query.backend.QueryInterceptor.visitPrepareCommand(QueryInterceptor.java:314)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:78)
> at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.visitPrepareCommand(OptimisticLockingInterceptor.java:87)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:125)
> at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:112)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:97)
> at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitPrepareCommand(TransactionSynchronizerInterceptor.java:42)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:217)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:147)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:75)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:97)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:97)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.transaction.impl.TransactionCoordinator.prepare(TransactionCoordinator.java:121)
> ... 30 more
> {noformat}
> http://ci.infinispan.org/viewLog.html?buildId=13514&tab=buildResultsDiv&b...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4887) Stale locks in non-tx cache after merge
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4887?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-4887:
----------------------------------
Fix Version/s: (was: 7.1.0.CR1)
> Stale locks in non-tx cache after merge
> ---------------------------------------
>
> Key: ISPN-4887
> URL: https://issues.jboss.org/browse/ISPN-4887
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 7.0.0.CR2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Blocker
> Labels: testsuite_stability
>
> It appears to cause random failures in {{ThreeNodesReplicatedSplitAndMergeTest.testSplitAndMerge0}}:
> {noformat}
> org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 10 seconds for key MagicKey#null{74043ff7@ThreeNodesReplicatedSplitAndMergeTest-NodeC-12710/9} and requestor Thread[testng-ThreeNodesReplicatedSplitAndMergeTest,5,main]. Lock is held by Thread[remote-thread-ThreeNodesReplicatedSplitAndMergeTest-NodeC-p5654-t5,5,main], while request came from null
> at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:198)
> at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLockNoCheck(LockManagerImpl.java:181)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockKey(AbstractLockingInterceptor.java:127)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockKey(AbstractLockingInterceptor.java:123)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(AbstractLockingInterceptor.java:47)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:33)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:33)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:172)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:95)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:33)
> at org.infinispan.partionhandling.impl.PartitionHandlingInterceptor.visitPutKeyValueCommand(PartitionHandlingInterceptor.java:34)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:33)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1512)
> at org.infinispan.cache.impl.CacheImpl.putInternal(CacheImpl.java:990)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:982)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1582)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:235)
> at org.infinispan.partitionhandling.ThreeNodesReplicatedSplitAndMergeTest.testSplitAndMerge(ThreeNodesReplicatedSplitAndMergeTest.java:132)
> at org.infinispan.partitionhandling.ThreeNodesReplicatedSplitAndMergeTest.testSplitAndMerge0(ThreeNodesReplicatedSplitAndMergeTest.java:27)
> {noformat}
> http://ci.infinispan.org/viewLog.html?buildId=13499&tab=buildResultsDiv&b...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4919) Configuration templates
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-4919:
----------------------------------
Fix Version/s: (was: 7.1.0.CR1)
> Configuration templates
> -----------------------
>
> Key: ISPN-4919
> URL: https://issues.jboss.org/browse/ISPN-4919
> Project: Infinispan
> Issue Type: Feature Request
> Components: Configuration
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
>
> Currently there is a 1:1 relationship between configuration and named caches. While the programmatic API does have the ability to .read() an existing configuration to create a new one, the declarative config does not.
> We should introduce the concept of configuration inheritance, e.g.:
> {code}
> <local-cache name="eviction-cache">
> <eviction strategy="LIRS" maxEntries="10000"/>
> </local-cache>
> <local-cache name="mycache" template="eviction-cache" />
> {code}
> Possibly, cache templates should be made "abstract" so that they cannot be instantiated as named caches directly, e.g.:
> {code}
> <local-cache name="eviction-cache" abstract="true">
> ...
> </local-cache>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4190) Use Message.Flag.DONT_LOOPBACK instead of RequestOptions.setExclusionList
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4190?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-4190:
----------------------------------
Fix Version/s: (was: 7.1.0.CR1)
> 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
>
> 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.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4262) Rolling back a transaction after commit timeout should release locks in two phases
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4262?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-4262:
----------------------------------
Fix Version/s: (was: 7.1.0.CR1)
> Rolling back a transaction after commit timeout should release locks in two phases
> ----------------------------------------------------------------------------------
>
> Key: ISPN-4262
> URL: https://issues.jboss.org/browse/ISPN-4262
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Transactions
> Affects Versions: 6.0.2.Final
> Reporter: Dan Berindei
>
> This is related to ISPN-4137.
> When a commit command times out, we send a rollback command to release locks. The problem is that the node that timed out might still execute commit command, before the rollback command reaching the backup but after it released the locks on the primary owner.
> The solution is to not release any locks during the rollback command's execution, but send an asynchronous TxCompletionNotification afterwards - just like for commit commands.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4351) Clarify the behaviour of putForExternalRead in clustered caches
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4351?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-4351:
----------------------------------
Fix Version/s: (was: 7.1.0.CR1)
> Clarify the behaviour of putForExternalRead in clustered caches
> ---------------------------------------------------------------
>
> Key: ISPN-4351
> URL: https://issues.jboss.org/browse/ISPN-4351
> Project: Infinispan
> Issue Type: Task
> Components: Core, Documentation-Core
> Affects Versions: 6.0.2.Final
> Reporter: Dan Berindei
>
> The {{putForExternal}} [documentation|http://infinispan.org/docs/7.0.x/user_guide/user_guide.html...] says
> {quote}
> putForExternalRead is consider to be a fast operation because regardless of whether it’s successful or not, it doesn’t wait for any locks, and so returns to the caller promptly.
> {quote}
> But the documentation doesn't say how {{putForExternalRead}} should behave in a clustered cache. Currently, the command is replicated to all the owners in distributed mode, and to all the cluster members in replicated mode. So the command may be delayed while waiting for the responses from those other nodes. The exception is invalidation mode, which doesn't replicate {{putForExternalRead}} commands - only regular {{put}}s generate invalidations.
> The documentation also doesn't mention the interaction of {{putForExternalRead}} operations with transactions. Currently, {{PUT_FOR_EXTERNAL_READ}}-flagged commands are executed as non-transactional commands even when the cache is transactional, presumably to avoid the overhead of transactions. But this undermines the argument for wrapping regular write operations in an implicit transaction, when running in a transactional cache.
> I propose changing {{putForExternalRead}} to only write on the local node (as it already does in invalidation mode), and documenting it as such. In distribution mode, it should be a no-op when the local node is not an owner.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months