[JBoss JIRA] (ISPN-11530) Only allow numOwners=1 and ALLOW_READ_WRITES strategy
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-11530?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes updated ISPN-11530:
-------------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Only allow numOwners=1 and ALLOW_READ_WRITES strategy
> -----------------------------------------------------
>
> Key: ISPN-11530
> URL: https://issues.redhat.com/browse/ISPN-11530
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, Core
> Affects Versions: 11.0.0.Dev03
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 11.0.0.Dev04, 10.1.6.Final
>
>
> DENY_READ_WRITES or ALLOW_READS results in the cluster becoming degraded in the event of a single node leaving the cluster, therefore we should throw an exception and explain that ALLOW_READ_WRITES should be used with numOwners=1.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-11459) NullPointerException installing continuous query listener on joiner
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-11459?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes updated ISPN-11459:
-------------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> NullPointerException installing continuous query listener on joiner
> -------------------------------------------------------------------
>
> Key: ISPN-11459
> URL: https://issues.redhat.com/browse/ISPN-11459
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 9.4.18.Final, 10.1.3.Final, 11.0.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.1.6.Final, 11.0.0.Dev03
>
>
> {noformat}
> 17:41:53,346 WARN (jgroups-4,Test-NodeD:[]) [StateConsumerImpl] ISPN000284: Problem encountered while installing cluster listener
> java.lang.NullPointerException: null
> at org.infinispan.notifications.impl.AbstractListenerImpl.canApply(AbstractListenerImpl.java:307) ~[classes/:?]
> at org.infinispan.notifications.impl.AbstractListenerImpl.validateAndAddFilterListenerInvocations(AbstractListenerImpl.java:271) ~[classes/:?]
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl.addFilteredListenerInternal(CacheNotifierImpl.java:1330) ~[classes/:?]
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl.addFilteredListenerAsync(CacheNotifierImpl.java:1293) ~[classes/:?]
> at org.infinispan.notifications.DataConversionAwareListenable.addFilteredListener(DataConversionAwareListenable.java:26) ~[classes/:?]
> at org.infinispan.notifications.cachelistener.cluster.ClusterListenerReplicateCallable.accept(ClusterListenerReplicateCallable.java:117) ~[classes/:?]
> at org.infinispan.statetransfer.StateConsumerImpl.lambda$fetchClusterListeners$6(StateConsumerImpl.java:526) ~[classes/:?]
> {noformat}
> {{AbstractCQMultipleCachesTest#testCQCacheLeavesAndJoins}} was supposed to test that continuous query keeps working after another node joins, but before the ISPN-11435 fix it only started a new cache manager, without starting the indexed cache. Now that all defined caches are started automatically, the test fails if the joiner becomes primary owner of key 5 (the only key that is included in the query results and is updated after the join):
> {noformat}
> Test failed: org.infinispan.query.continuous.ContinuousQueryMultipleCachesDistTest.testCQCacheLeavesAndJoins
> java.lang.AssertionError: expected:<6> but was:<5>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252)
> at org.infinispan.query.continuous.AbstractCQMultipleCachesTest.testCQCacheLeavesAndJoins(AbstractCQMultipleCachesTest.java:161)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-11530) Only allow numOwners=1 and ALLOW_READ_WRITES strategy
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-11530?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes updated ISPN-11530:
-------------------------------------
Fix Version/s: 10.1.6.Final
> Only allow numOwners=1 and ALLOW_READ_WRITES strategy
> -----------------------------------------------------
>
> Key: ISPN-11530
> URL: https://issues.redhat.com/browse/ISPN-11530
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, Core
> Affects Versions: 11.0.0.Dev03
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 11.0.0.Dev04, 10.1.6.Final
>
>
> DENY_READ_WRITES or ALLOW_READS results in the cluster becoming degraded in the event of a single node leaving the cluster, therefore we should throw an exception and explain that ALLOW_READ_WRITES should be used with numOwners=1.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-11296) StateResponseOrderingTest uncaught IllegalArgumentException
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11296?page=com.atlassian.jira.plugi... ]
Dan Berindei edited comment on ISPN-11296 at 4/3/20 3:41 AM:
-------------------------------------------------------------
Fix included accidentally in the ISPN-11367 PRs.
The remaining problem was that {{InboundRpcSequencerAction}} was advancing to the "after" states twice: once in the {{finally}} block, and again after {{PerCacheInboundInvocationHandler.handle()}} asynchronously processed the command.
was (Author: dan.berindei):
Included accidentally in the ISPN-11367 PRs.
> StateResponseOrderingTest uncaught IllegalArgumentException
> -----------------------------------------------------------
>
> Key: ISPN-11296
> URL: https://issues.redhat.com/browse/ISPN-11296
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite
> Affects Versions: 10.1.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.1.4.Final, 11.0.0.Dev03
>
>
> I think initially I wanted {{MatchCountMatcher}} to count from 1 and handle {{matchCount == 0}} as matching all invocations. All the callers now assume 0 is the first invocation, but the code kept working because the exception was not caught.
> {noformat}
> java.lang.IllegalStateException: State st:after_first_state_response exited twice
> at org.infinispan.test.concurrent.StateSequencer.exit(StateSequencer.java:242)
> at org.infinispan.test.concurrent.StateSequencer.advance(StateSequencer.java:316)
> at org.infinispan.test.concurrent.StateSequencerUtil.advanceMultiple(StateSequencerUtil.java:103)
> at org.infinispan.test.concurrent.InboundRpcSequencerAction$SequencerPerCacheInboundInvocationHandler.advance(InboundRpcSequencerAction.java:101)
> at org.infinispan.test.concurrent.InboundRpcSequencerAction$SequencerPerCacheInboundInvocationHandler.lambda$handle$0(InboundRpcSequencerAction.java:82)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invokedComplete(BaseBlockingRunnable.java:130)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:111)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:72)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:41)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-11296) StateResponseOrderingTest uncaught IllegalArgumentException
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11296?page=com.atlassian.jira.plugi... ]
Dan Berindei resolved ISPN-11296.
---------------------------------
Fix Version/s: 11.0.0.Dev03
10.1.4.Final
(was: 11.0.0.Dev04)
Resolution: Done
Included accidentally in the ISPN-11367 PRs.
> StateResponseOrderingTest uncaught IllegalArgumentException
> -----------------------------------------------------------
>
> Key: ISPN-11296
> URL: https://issues.redhat.com/browse/ISPN-11296
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite
> Affects Versions: 10.1.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 11.0.0.Dev03, 10.1.4.Final
>
>
> I think initially I wanted {{MatchCountMatcher}} to count from 1 and handle {{matchCount == 0}} as matching all invocations. All the callers now assume 0 is the first invocation, but the code kept working because the exception was not caught.
> {noformat}
> java.lang.IllegalStateException: State st:after_first_state_response exited twice
> at org.infinispan.test.concurrent.StateSequencer.exit(StateSequencer.java:242)
> at org.infinispan.test.concurrent.StateSequencer.advance(StateSequencer.java:316)
> at org.infinispan.test.concurrent.StateSequencerUtil.advanceMultiple(StateSequencerUtil.java:103)
> at org.infinispan.test.concurrent.InboundRpcSequencerAction$SequencerPerCacheInboundInvocationHandler.advance(InboundRpcSequencerAction.java:101)
> at org.infinispan.test.concurrent.InboundRpcSequencerAction$SequencerPerCacheInboundInvocationHandler.lambda$handle$0(InboundRpcSequencerAction.java:82)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invokedComplete(BaseBlockingRunnable.java:130)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:111)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:72)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:41)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-11296) StateResponseOrderingTest uncaught IllegalArgumentException
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11296?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11296:
-----------------------------------
Status: Open (was: Pull Request Sent)
> StateResponseOrderingTest uncaught IllegalArgumentException
> -----------------------------------------------------------
>
> Key: ISPN-11296
> URL: https://issues.redhat.com/browse/ISPN-11296
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite
> Affects Versions: 10.1.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 11.0.0.Dev04
>
>
> I think initially I wanted {{MatchCountMatcher}} to count from 1 and handle {{matchCount == 0}} as matching all invocations. All the callers now assume 0 is the first invocation, but the code kept working because the exception was not caught.
> {noformat}
> java.lang.IllegalStateException: State st:after_first_state_response exited twice
> at org.infinispan.test.concurrent.StateSequencer.exit(StateSequencer.java:242)
> at org.infinispan.test.concurrent.StateSequencer.advance(StateSequencer.java:316)
> at org.infinispan.test.concurrent.StateSequencerUtil.advanceMultiple(StateSequencerUtil.java:103)
> at org.infinispan.test.concurrent.InboundRpcSequencerAction$SequencerPerCacheInboundInvocationHandler.advance(InboundRpcSequencerAction.java:101)
> at org.infinispan.test.concurrent.InboundRpcSequencerAction$SequencerPerCacheInboundInvocationHandler.lambda$handle$0(InboundRpcSequencerAction.java:82)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invokedComplete(BaseBlockingRunnable.java:130)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:111)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:72)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:41)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-11113) ScatteredDelayedAvailabilityUpdateTest takes too long
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11113?page=com.atlassian.jira.plugi... ]
Tristan Tarrant closed ISPN-11113.
----------------------------------
> ScatteredDelayedAvailabilityUpdateTest takes too long
> -----------------------------------------------------
>
> Key: ISPN-11113
> URL: https://issues.redhat.com/browse/ISPN-11113
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite
> Affects Versions: 10.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Minor
> Fix For: 10.1.1.Final
>
>
> Partition handling tests use {{LOCAL_PING.setClusterName()}} with a unique name to disable discovery, otherwise partitions would try to merge while they are supposed to stay separate.
> But {{LOCAL_PING}} uses the cluster name on stop to remove the node from the static discovery map. If the test doesn't change the cluster name back, {{LOCAL_PING}} doesn't remove the node, the next test method sees an existing coordinator, and tries to connect to it. When a test has lots of test methods, like {{ScatteredDelayedAvailabilityUpdateTest}}, each test method leaves one more coordinator in the discovery map, and each test method takes longer to start the first method.
> {noformat}
> 09:08:52,758 DEBUG (testng:[]) [GMS] address=NodeA-30899, cluster=org.infinispan.partitionhandling.ScatteredDelayedAvailabilityUpdateTest[SCATTERED_SYNC, bias=NEVER, DENY_READ_WRITES], physical address=127.0.0.1:51941
> 09:08:52,774 TRACE (testng:[]) [GMS] NodeA-30899: discovery took 0 ms, members: 21 rsps (5 coords) [done]
> 09:08:52,774 DEBUG (testng:[]) [GMS] NodeA-30899: found multiple coords: [NodeA-2608, NodeA-5606, NodeA-17288, NodeA-64297, NodeA-48475]
> 09:08:52,774 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-5606
> 09:08:54,774 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-5606 timed out (after 2000 ms), on try 0
> 09:08:54,774 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-64297
> 09:08:56,775 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-64297 timed out (after 2000 ms), on try 0
> 09:08:56,775 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-48475
> 09:08:58,775 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-48475 timed out (after 2000 ms), on try 0
> 09:08:58,775 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-17288
> 09:09:00,776 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-17288 timed out (after 2000 ms), on try 0
> 09:09:00,776 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-2608
> 09:09:02,776 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-2608 timed out (after 2000 ms), on try 0
> 09:09:02,776 TRACE (testng:[]) [GMS] NodeA-30899: discovery took 0 ms, members: 21 rsps (5 coords) [done]
> 09:09:02,776 DEBUG (testng:[]) [GMS] NodeA-30899: found multiple coords: [NodeA-2608, NodeA-5606, NodeA-17288, NodeA-64297, NodeA-48475]
> 09:09:02,776 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-5606
> 09:09:04,776 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-5606 timed out (after 2000 ms), on try 1
> ...
> 09:09:12,777 TRACE (testng:[]) [GMS] NodeA-30899: discovery took 0 ms, members: 21 rsps (5 coords) [done]
> 09:09:12,778 DEBUG (testng:[]) [GMS] NodeA-30899: found multiple coords: [NodeA-2608, NodeA-5606, NodeA-17288, NodeA-64297, NodeA-48475]
> 09:09:12,778 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-2608
> 09:09:14,778 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-2608 timed out (after 2000 ms), on try 2
> ...
> 09:09:22,780 WARN (testng:[]) [GMS] NodeA-30899: too many JOIN attempts (3): becoming singleton
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-11113) ScatteredDelayedAvailabilityUpdateTest takes too long
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11113?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11113:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 10.1.1.Final
(was: 11.0.0.Final)
(was: 10.1.6.Final)
Resolution: Done
> ScatteredDelayedAvailabilityUpdateTest takes too long
> -----------------------------------------------------
>
> Key: ISPN-11113
> URL: https://issues.redhat.com/browse/ISPN-11113
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite
> Affects Versions: 10.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Minor
> Fix For: 10.1.1.Final
>
>
> Partition handling tests use {{LOCAL_PING.setClusterName()}} with a unique name to disable discovery, otherwise partitions would try to merge while they are supposed to stay separate.
> But {{LOCAL_PING}} uses the cluster name on stop to remove the node from the static discovery map. If the test doesn't change the cluster name back, {{LOCAL_PING}} doesn't remove the node, the next test method sees an existing coordinator, and tries to connect to it. When a test has lots of test methods, like {{ScatteredDelayedAvailabilityUpdateTest}}, each test method leaves one more coordinator in the discovery map, and each test method takes longer to start the first method.
> {noformat}
> 09:08:52,758 DEBUG (testng:[]) [GMS] address=NodeA-30899, cluster=org.infinispan.partitionhandling.ScatteredDelayedAvailabilityUpdateTest[SCATTERED_SYNC, bias=NEVER, DENY_READ_WRITES], physical address=127.0.0.1:51941
> 09:08:52,774 TRACE (testng:[]) [GMS] NodeA-30899: discovery took 0 ms, members: 21 rsps (5 coords) [done]
> 09:08:52,774 DEBUG (testng:[]) [GMS] NodeA-30899: found multiple coords: [NodeA-2608, NodeA-5606, NodeA-17288, NodeA-64297, NodeA-48475]
> 09:08:52,774 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-5606
> 09:08:54,774 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-5606 timed out (after 2000 ms), on try 0
> 09:08:54,774 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-64297
> 09:08:56,775 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-64297 timed out (after 2000 ms), on try 0
> 09:08:56,775 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-48475
> 09:08:58,775 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-48475 timed out (after 2000 ms), on try 0
> 09:08:58,775 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-17288
> 09:09:00,776 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-17288 timed out (after 2000 ms), on try 0
> 09:09:00,776 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-2608
> 09:09:02,776 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-2608 timed out (after 2000 ms), on try 0
> 09:09:02,776 TRACE (testng:[]) [GMS] NodeA-30899: discovery took 0 ms, members: 21 rsps (5 coords) [done]
> 09:09:02,776 DEBUG (testng:[]) [GMS] NodeA-30899: found multiple coords: [NodeA-2608, NodeA-5606, NodeA-17288, NodeA-64297, NodeA-48475]
> 09:09:02,776 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-5606
> 09:09:04,776 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-5606 timed out (after 2000 ms), on try 1
> ...
> 09:09:12,777 TRACE (testng:[]) [GMS] NodeA-30899: discovery took 0 ms, members: 21 rsps (5 coords) [done]
> 09:09:12,778 DEBUG (testng:[]) [GMS] NodeA-30899: found multiple coords: [NodeA-2608, NodeA-5606, NodeA-17288, NodeA-64297, NodeA-48475]
> 09:09:12,778 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-2608
> 09:09:14,778 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-2608 timed out (after 2000 ms), on try 2
> ...
> 09:09:22,780 WARN (testng:[]) [GMS] NodeA-30899: too many JOIN attempts (3): becoming singleton
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years