[JBoss JIRA] (ISPN-2645) LocalKeyAffinityServiceTest.testFilteredRemoveServers fails randomly
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2645?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2645:
--------------------------------
Fix Version/s: (was: 6.0.0.Alpha1)
> LocalKeyAffinityServiceTest.testFilteredRemoveServers fails randomly
> --------------------------------------------------------------------
>
> Key: ISPN-2645
> URL: https://issues.jboss.org/browse/ISPN-2645
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache, Test Suite
> Affects Versions: 5.2.0.Beta5
> Reporter: Dan Berindei
> Assignee: Mircea Markus
> Labels: testsuite_stability
>
> LocalKeyAffinityServiceTest tests that KeyAffinnityServiceImpl's internal queues eventually fill up, and it fails:
> {noformat}
> java.lang.AssertionError: expected [true] but found [false]
> at org.testng.Assert.fail(Assert.java:89)
> at org.testng.Assert.failNotEquals(Assert.java:489)
> at org.testng.Assert.assertTrue(Assert.java:37)
> at org.testng.Assert.assertTrue(Assert.java:47)
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:76)
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:59)
> at org.infinispan.affinity.BaseKeyAffinityServiceTest.assertEventualFullCapacity(BaseKeyAffinityServiceTest.java:98)
> at org.infinispan.affinity.BaseFilterKeyAffinityServiceTest.assertUnaffected(BaseFilterKeyAffinityServiceTest.java:108)
> at org.infinispan.affinity.BaseFilterKeyAffinityServiceTest.testRemoveServers(BaseFilterKeyAffinityServiceTest.java:82)
> at org.infinispan.affinity.LocalKeyAffinityServiceTest.testFilteredRemoveServers(LocalKeyAffinityServiceTest.java:66)
> {noformat}
> I have added some TRACE logs to KeyAffinityServiceImpl and it looks like the queue fills up immediately, but it could be that a new queue is created and the test is checking the wrong queue object.
--
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
12 years, 9 months
[JBoss JIRA] (ISPN-2645) LocalKeyAffinityServiceTest.testFilteredRemoveServers fails randomly
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2645?page=com.atlassian.jira.plugin.... ]
Mircea Markus resolved ISPN-2645.
---------------------------------
Resolution: Out of Date
Seems to be stable now[1], re-open when needed. http://ci.infinispan.org/project.html?projectId=project2&testNameId=-8556...
> LocalKeyAffinityServiceTest.testFilteredRemoveServers fails randomly
> --------------------------------------------------------------------
>
> Key: ISPN-2645
> URL: https://issues.jboss.org/browse/ISPN-2645
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache, Test Suite
> Affects Versions: 5.2.0.Beta5
> Reporter: Dan Berindei
> Assignee: Mircea Markus
> Labels: testsuite_stability
> Fix For: 6.0.0.Alpha1
>
>
> LocalKeyAffinityServiceTest tests that KeyAffinnityServiceImpl's internal queues eventually fill up, and it fails:
> {noformat}
> java.lang.AssertionError: expected [true] but found [false]
> at org.testng.Assert.fail(Assert.java:89)
> at org.testng.Assert.failNotEquals(Assert.java:489)
> at org.testng.Assert.assertTrue(Assert.java:37)
> at org.testng.Assert.assertTrue(Assert.java:47)
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:76)
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:59)
> at org.infinispan.affinity.BaseKeyAffinityServiceTest.assertEventualFullCapacity(BaseKeyAffinityServiceTest.java:98)
> at org.infinispan.affinity.BaseFilterKeyAffinityServiceTest.assertUnaffected(BaseFilterKeyAffinityServiceTest.java:108)
> at org.infinispan.affinity.BaseFilterKeyAffinityServiceTest.testRemoveServers(BaseFilterKeyAffinityServiceTest.java:82)
> at org.infinispan.affinity.LocalKeyAffinityServiceTest.testFilteredRemoveServers(LocalKeyAffinityServiceTest.java:66)
> {noformat}
> I have added some TRACE logs to KeyAffinityServiceImpl and it looks like the queue fills up immediately, but it could be that a new queue is created and the test is checking the wrong queue object.
--
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
12 years, 9 months
[JBoss JIRA] (ISPN-2702) RecoveryWithCustomCacheDistTest.testNodeCrashesAfterPrepare failing randomly
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2702?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2702:
--------------------------------
Assignee: Pedro Ruivo (was: Mircea Markus)
> RecoveryWithCustomCacheDistTest.testNodeCrashesAfterPrepare failing randomly
> ----------------------------------------------------------------------------
>
> Key: ISPN-2702
> URL: https://issues.jboss.org/browse/ISPN-2702
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Reporter: Galder Zamarreño
> Assignee: Pedro Ruivo
> Labels: testsuite_stability
> Fix For: 6.0.0.Alpha1
>
> Attachments: RecoveryWithCustomCacheDistTest.log.gz, testNodeCrashesAfterPrepare-1.log
>
>
> {code}testNodeCrashesAfterPrepare(org.infinispan.tx.recovery.RecoveryWithCustomCacheDistTest) Time elapsed: 0.083 sec <<< FAILURE!
> java.lang.RuntimeException: javax.transaction.xa.XAException
> at org.infinispan.tx.recovery.RecoveryTestUtil.prepareTransaction(RecoveryTestUtil.java:58)
> at org.infinispan.tx.recovery.RecoveryWithDefaultCacheDistTest.testNodeCrashesAfterPrepare(RecoveryWithDefaultCacheDistTest.java:124)
> 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)
> 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.xa.TransactionXaAdapter.prepare(TransactionXaAdapter.java:110)
> at org.infinispan.tx.recovery.RecoveryTestUtil.prepareTransaction(RecoveryTestUtil.java:56)
> ... 22 more{code}
--
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
12 years, 9 months
[JBoss JIRA] (ISPN-3051) Allow configuring the number of segments per node
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3051?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3051:
--------------------------------
Fix Version/s: 6.0.0.Alpha2
6.0.0.Final
> Allow configuring the number of segments per node
> -------------------------------------------------
>
> Key: ISPN-3051
> URL: https://issues.jboss.org/browse/ISPN-3051
> Project: Infinispan
> Issue Type: Feature Request
> Components: Distributed Cache
> Reporter: Guillermo GARCIA OCHOA
> Assignee: Dan Berindei
> Fix For: 6.0.0.Alpha2, 6.0.0.Final
>
>
> This should allow for the following use cases:
> - a node to take more load
> - a node to take no load
> A simple way for specifying this would be to configure a load factor per node, e.g. more powerful machine would be 2*x and that would mean that it would take twice the load of an "ordinary" machine in the cluster.
--
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
12 years, 9 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 updated ISPN-604:
-------------------------------
Parent: ISPN-3290
Issue Type: Sub-task (was: Feature Request)
> 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.Beta1, 6.0.0.Final
>
>
> 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
12 years, 9 months