[JBoss JIRA] (ISPN-7098) FunctionalDistributionTest.testDistributionFromPrimaryOwner random failures
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7098?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7098:
----------------------------------
Fix Version/s: 9.0.0.Beta2
(was: 9.0.0.Beta1)
> FunctionalDistributionTest.testDistributionFromPrimaryOwner random failures
> ---------------------------------------------------------------------------
>
> Key: ISPN-7098
> URL: https://issues.jboss.org/browse/ISPN-7098
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 9.0.0.Alpha4
> Reporter: Dan Berindei
> Priority: Critical
> Labels: testsuite_stability
> Fix For: 9.0.0.Beta2
>
>
> {{FunctionalDistributionTest.testDistributionFromPrimaryOwner}} assumes 100ms is enough for the command to be executed on both backup owners, but that's not always true -- e.g. when TRACE logging is enabled.
> {noformat}
> 15:27:36,079 TRACE (async-thread-Test-NodeC-p36570-t1:[]) [InvocationContextInterceptor] Invoked with command ReadWriteKeyCommand {key=testDistributionFromPrimaryOwner, flags=[]} and InvocationContext [org.infinispan.context.SingleKeyNonTxInvocationContext@44ffeec2]
> 15:27:36,124 TRACE (async-thread-Test-NodeC-p36570-t1:[]) [JGroupsTransport] dests=[Test-NodeC-21089, Test-NodeD-31203], command=SingleRpcCommand{cacheName='dist', command=ReadWriteKeyCommand {key=testDistributionFromPrimaryOwner, flags=[]}}, mode=ASYNCHRONOUS, timeout=15000
> 15:27:36,140 TRACE (async-thread-Test-NodeC-p36570-t1:[]) [DefaultDataContainer] Store MetadataImmortalCacheEntry{key=testDistributionFromPrimaryOwner, value=1, metadata=MetaParamsInternalMetadata{params=MetaParams{metas=[]}}} in container
> 15:27:36,144 TRACE (Incoming-1,Test-NodeD-31203:[]) [InvocationContextInterceptor] Invoked with command ReadWriteKeyCommand {key=testDistributionFromPrimaryOwner, flags=[]} and InvocationContext [org.infinispan.context.SingleKeyNonTxInvocationContext@73111d9]
> 15:27:36,241 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.functional.FunctionalDistributionTest.testDistributionFromPrimaryOwner
> java.lang.NullPointerException
> at org.infinispan.functional.FunctionalDistributionTest.lambda$iterate$8(FunctionalDistributionTest.java:101) ~[test-classes/:?]
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) ~[?:1.8.0_101]
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) ~[?:1.8.0_101]
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) ~[?:1.8.0_101]
> at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374) ~[?:1.8.0_101]
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) ~[?:1.8.0_101]
> at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) ~[?:1.8.0_101]
> at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) ~[?:1.8.0_101]
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:1.8.0_101]
> at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499) ~[?:1.8.0_101]
> at org.infinispan.functional.FunctionalDistributionTest.iterate(FunctionalDistributionTest.java:102) ~[test-classes/:?]
> at org.infinispan.functional.FunctionalDistributionTest.doTestDistribution(FunctionalDistributionTest.java:80) ~[test-classes/:?]
> at org.infinispan.functional.FunctionalDistributionTest.testDistributionFromPrimaryOwner(FunctionalDistributionTest.java:46) ~[test-classes/:?]
> 15:27:36,259 TRACE (Incoming-1,Test-NodeD-31203:[]) [DefaultDataContainer] Store MetadataImmortalCacheEntry{key=testDistributionFromPrimaryOwner, value=1, metadata=MetaParamsInternalMetadata{params=MetaParams{metas=[]}}} in container
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (ISPN-6997) PessimisticTxPartitionAndMergeDuringRuntimeTest.testOriginatorIsolatedPartition random failures
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6997?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6997:
----------------------------------
Fix Version/s: 9.0.0.Beta2
(was: 9.0.0.Beta1)
> PessimisticTxPartitionAndMergeDuringRuntimeTest.testOriginatorIsolatedPartition random failures
> -----------------------------------------------------------------------------------------------
>
> Key: ISPN-6997
> URL: https://issues.jboss.org/browse/ISPN-6997
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 9.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 9.0.0.Beta2
>
>
> The test starts with a cluster of 4 nodes, and splits it in 2 partitions while a transaction is trying to lock a key. After the transaction fails, it checks that the transaction has been cleaned up properly.
> On one of the owners, {{transactionTable.cleanupLeaverTransactions}} is being called only before the split and after the merge, never with the list of members during the split. That means it never sees the transaction as an orphan, and doesn't remove it.
> {noformat}
> 15:16:18,893 TRACE (testng-PTPAMDRT:[]) [PTPAMDRT] Local tx=[], remote tx=[GlobalTx:PTPAMDRT-NodeI-3337:28616], for cache PTPAMDRT-NodeJ-27814
> 15:16:18,893 ERROR (testng-PTPAMDRT:[]) [TestSuiteProgress] Test failed: org.infinispan.partitionhandling.PTPAMDRT.testOriginatorIsolatedPartition
> java.lang.AssertionError: There are pending transactions!
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?]
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) ~[testng-6.8.8.jar:?]
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:223) ~[test-classes/:?]
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:519) ~[test-classes/:?]
> at org.infinispan.test.MultipleCacheManagersTest.assertNoTransactions(MultipleCacheManagersTest.java:794) ~[test-classes/:?]
> at org.infinispan.partitionhandling.BaseTxPartitionAndMergeTest.finalAsserts(BaseTxPartitionAndMergeTest.java:96) ~[test-classes/:?]
> at org.infinispan.partitionhandling.BasePessimisticTxPartitionAndMergeTest.doTest(BasePessimisticTxPartitionAndMergeTest.java:82) ~[test-classes/:?]
> at org.infinispan.partitionhandling.tionAndMergeDuringRuntimeTest.testOriginatorIsolatedPartition(PessimisticTxPartitionAndMergeDuringRuntimeTest.java:33) ~[test-classes/:?]
> {noformat}
> {{OptimisticTxPartitionAndMergeDuringCommitTest.testPrimaryOwnerIsolatedPartition}} has similar random failures.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (ISPN-7026) CacheClusterJoinTest.testIsCoordinator random failures
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7026?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7026:
----------------------------------
Fix Version/s: 9.0.0.Beta2
(was: 9.0.0.Beta1)
> CacheClusterJoinTest.testIsCoordinator random failures
> ------------------------------------------------------
>
> Key: ISPN-7026
> URL: https://issues.jboss.org/browse/ISPN-7026
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 9.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 9.0.0.Beta2
>
>
> {{CacheClusterJoinTest.testIsCoordinator}} assumes that once {{JGroupsTransport}} received a view, {{JGroupsTransport.isCoordinator()}} returns the correct value.
> However, only {{JGroupsTransfer.viewAccepted}} is synchronized, {{isCoordinator()}} is not, so the main thread can see {{isCoordinator() == false}} even after {{getMembers().get(0) == self}}.
> {noformat}
> 19:32:27,555 DEBUG (Incoming-1,Test-NodeD-36891:[]) [JGroupsTransport] New view accepted: [Test-NodeD-36891|2] (1) [Test-NodeD-36891]
> 19:32:27,556 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.api.CacheClusterJoinTest.testIsCoordinator
> java.lang.AssertionError
> at org.infinispan.api.CacheClusterJoinTest.testIsCoordinator(CacheClusterJoinTest.java:65) ~[test-classes/:?]
> 19:32:27,555 DEBUG (Incoming-1,Test-NodeD-36891:[]) [JGroupsTransport] Joined: [], Left: [Test-NodeC-35712]
> {noformat}
> It would be nice if {{isCoordinator()}}, {{getCoordinator()}}, and {{getMembers()}} were more in sync, even though the view can always change between two calls. The simplest way to do this would be to implement {{isCoordinator()}} and {{getCoordinator()}} on top of {{getMembers()}} and remove their fields, since they're not use in performance-sensitive code.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (ISPN-7011) @AfterClass cleanup doesn't work with @InTransactionMode
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7011?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7011:
----------------------------------
Fix Version/s: 9.0.0.Beta2
(was: 9.0.0.Beta1)
> @AfterClass cleanup doesn't work with @InTransactionMode
> --------------------------------------------------------
>
> Key: ISPN-7011
> URL: https://issues.jboss.org/browse/ISPN-7011
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Minor
> Labels: testsuite_stability
> Fix For: 9.0.0.Beta2
>
>
> Very much like ISPN-7003, TestNG's {{TestMethodWorker.invokeAfterClassMethods}} never sees an empty list of methods in {{m_classMethodMap}}. That happens because {{m_classMethodMap}} is populated before our {{ChainMethodInterceptor}} had a chance to filter the methods (e.g. when a test method has an {{@InTransactionMode}} annotation).
> Normally this is not a problem because each test has a different name, and the test suite tolerates some leaked managers. But when you run a test like {{PutForExternalReadTest}} with {{-Dtest.infinispan.shortTestName=true}}, you get this failure:
> {noformat}
> java.lang.IllegalStateException: Two tests with the same name running in parallel: test
> at org.infinispan.test.fwk.TestResourceTracker.testStarted(TestResourceTracker.java:88)
> at org.infinispan.test.AbstractInfinispanTest.testClassStarted(AbstractInfinispanTest.java:115)
> 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.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:138)
> at org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:175)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:107)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (ISPN-7283) Make remote event supporting cluster listener more fine grained
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7283?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7283:
----------------------------------
Fix Version/s: 9.0.0.Beta2
(was: 9.0.0.Beta1)
> Make remote event supporting cluster listener more fine grained
> ---------------------------------------------------------------
>
> Key: ISPN-7283
> URL: https://issues.jboss.org/browse/ISPN-7283
> Project: Infinispan
> Issue Type: Bug
> Components: Listeners, Remote Protocols
> Affects Versions: 9.0.0.Alpha4, 8.2.5.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 9.0.0.Beta2, 8.2.6.Final
>
>
> Make server side cluster listener used for supporting remote events more fine grained. Right now if a client registers for created events, server side all nodes push all currently supported events over to the node where the remote listener is located: created, modified, removed and expired. Having all these events being passed around the cluster creates unnecessary load which can create problems in other nodes.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (ISPN-7238) Reduce number of CompletableFuture allocations during async invocation
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7238?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7238:
----------------------------------
Fix Version/s: 9.0.0.Beta2
(was: 9.0.0.Beta1)
> Reduce number of CompletableFuture allocations during async invocation
> ----------------------------------------------------------------------
>
> Key: ISPN-7238
> URL: https://issues.jboss.org/browse/ISPN-7238
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.0.0.Beta2
>
>
> The current asynchronous invocations allocate a new {{CompletableFuture}} instance (plus a {{UniHandle}}, and a {{ComposedAsyncInvocationStage}}) for every interceptor that calls {{compose()}} or the other {{InvocationState}} methods that add a callback.
> We can reduce this by having a list of handlers in each invocation stage, and only creating a new {{CompletableFuture}} when we need to change the {{command}}.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (ISPN-7235) Cross site replication fails if authentication is enabled
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7235?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7235:
----------------------------------
Fix Version/s: 9.0.0.Beta2
(was: 9.0.0.Beta1)
> Cross site replication fails if authentication is enabled
> ---------------------------------------------------------
>
> Key: ISPN-7235
> URL: https://issues.jboss.org/browse/ISPN-7235
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication, Security
> Affects Versions: 9.0.0.Alpha4, 8.2.5.Final
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 9.0.0.Beta2, 8.2.6.Final
>
>
> org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (Incoming-2,shared=tcp-global) ISPN000071: Caught exception when handling command SingleXSiteRpcCommand{command=ClearCommand{flags=null}}: java.lang.SecurityException: ISPN000287: Unauthorized access: subject 'null' lacks 'ADMIN' permission
> at org.infinispan.security.impl.AuthorizationHelper.checkPermission(AuthorizationHelper.java:76)
> at org.infinispan.security.impl.AuthorizationManagerImpl.checkPermission(AuthorizationManagerImpl.java:44)
> at org.infinispan.security.impl.SecureCacheImpl.getCacheConfiguration(SecureCacheImpl.java:454)
> at org.infinispan.xsite.BackupReceiverRepositoryImpl.createBackupReceiver(BackupReceiverRepositoryImpl.java:163)
> at org.infinispan.xsite.BackupReceiverRepositoryImpl.getBackupReceiver(BackupReceiverRepositoryImpl.java:95)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromRemoteSite(CommandAwareRpcDispatcher.java:283)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:252)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:460) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:377) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:250) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:675) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.JChannel.up(JChannel.java:739) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1029) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.protocols.relay.RELAY2.deliver(RELAY2.java:618) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.protocols.relay.RELAY2.route(RELAY2.java:514) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.protocols.relay.RELAY2.handleMessage(RELAY2.java:489) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.protocols.relay.RELAY2.handleRelayMessage(RELAY2.java:470) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.protocols.relay.Relayer$Bridge.receive(Relayer.java:265) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.JChannel.up(JChannel.java:769) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1033) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:182) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:447) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.stack.Protocol.up(Protocol.java:420) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.protocols.UNICAST3.deliverBatch(UNICAST3.java:1087) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.protocols.UNICAST3.removeAndDeliver(UNICAST3.java:886) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:790) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:652) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:299) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:286) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.protocols.Discovery.up(Discovery.java:291) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2842) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1577) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at org.jgroups.protocols.TP$MyHandler.run(TP.java:1796) [jgroups-3.6.3.Final-redhat-6.jar:3.6.3.Final-redhat-6]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_101]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_101]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_101]
> ~~~
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (ISPN-7167) ExampleConfigsIT.testTopologyConfigRackAttribute random failures
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7167?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7167:
----------------------------------
Fix Version/s: 9.0.0.Beta2
(was: 9.0.0.Beta1)
> ExampleConfigsIT.testTopologyConfigRackAttribute random failures
> -----------------------------------------------------------------
>
> Key: ISPN-7167
> URL: https://issues.jboss.org/browse/ISPN-7167
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 9.0.0.Alpha4
> Reporter: Dan Berindei
> Priority: Critical
> Labels: testsuite_stability
> Fix For: 9.0.0.Beta2
>
>
> {noformat}
> java.lang.AssertionError: Unexpected number of entries in server1: 0
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.infinispan.server.test.configs.ExampleConfigsIT.verifyTopologyHinting(ExampleConfigsIT.java:482)
> at org.infinispan.server.test.configs.ExampleConfigsIT.testTopologyConfigRackAttribute(ExampleConfigsIT.java:419)
> {noformat}
> The test is also inconsistent about the names of the servers, sometimes it starts counting from 0 and sometimes it starts counting from 1.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months