[JBoss JIRA] (ELY-1902) Support for multiple security realms - Failover
by Martin Mazanek (Jira)
[ https://issues.jboss.org/browse/ELY-1902?page=com.atlassian.jira.plugin.s... ]
Martin Mazanek moved WFCORE-4747 to ELY-1902:
---------------------------------------------
Project: WildFly Elytron (was: WildFly Core)
Key: ELY-1902 (was: WFCORE-4747)
Component/s: (was: Security)
Fix Version/s: (was: 11.0.0.Beta3)
> Support for multiple security realms - Failover
> -----------------------------------------------
>
> Key: ELY-1902
> URL: https://issues.jboss.org/browse/ELY-1902
> Project: WildFly Elytron
> Issue Type: Feature Request
> Reporter: Martin Mazanek
> Assignee: Martin Mazanek
> Priority: Major
> Labels: CD17-Deferred, EAP-CD19
>
> Our security realms are able to indicate unavailability by throwing a RealmUnavailableException
> We should support fail over to an alternative realm.
> A common request is fail over to a local file based realm if an LDAP or database server has gone down allowing administrators to retain access to the server.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ELY-1902) Support for multiple security realms - Failover
by Martin Mazanek (Jira)
[ https://issues.jboss.org/browse/ELY-1902?page=com.atlassian.jira.plugin.s... ]
Martin Mazanek updated ELY-1902:
--------------------------------
Component/s: Realms
> Support for multiple security realms - Failover
> -----------------------------------------------
>
> Key: ELY-1902
> URL: https://issues.jboss.org/browse/ELY-1902
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Realms
> Reporter: Martin Mazanek
> Assignee: Martin Mazanek
> Priority: Major
> Labels: CD17-Deferred, EAP-CD19
>
> Our security realms are able to indicate unavailability by throwing a RealmUnavailableException
> We should support fail over to an alternative realm.
> A common request is fail over to a local file based realm if an LDAP or database server has gone down allowing administrators to retain access to the server.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFCORE-4486) Support for multiple security realms - Failover
by Martin Mazanek (Jira)
[ https://issues.jboss.org/browse/WFCORE-4486?page=com.atlassian.jira.plugi... ]
Martin Mazanek reassigned WFCORE-4486:
--------------------------------------
Assignee: Martin Mazanek
> Support for multiple security realms - Failover
> -----------------------------------------------
>
> Key: WFCORE-4486
> URL: https://issues.jboss.org/browse/WFCORE-4486
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Farah Juma
> Assignee: Martin Mazanek
> Priority: Major
> Labels: CD17-Deferred, EAP-CD19
> Fix For: 11.0.0.Beta3
>
>
> Our security realms are able to indicate unavailability by throwing a RealmUnavailableException
> We should support fail over to an alternative realm.
> A common request is fail over to a local file based realm if an LDAP or database server has gone down allowing administrators to retain access to the server.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFCORE-4747) Support for multiple security realms - Failover
by Martin Mazanek (Jira)
Martin Mazanek created WFCORE-4747:
--------------------------------------
Summary: Support for multiple security realms - Failover
Key: WFCORE-4747
URL: https://issues.jboss.org/browse/WFCORE-4747
Project: WildFly Core
Issue Type: Feature Request
Components: Security
Reporter: Martin Mazanek
Assignee: Martin Mazanek
Fix For: 11.0.0.Beta3
Our security realms are able to indicate unavailability by throwing a RealmUnavailableException
We should support fail over to an alternative realm.
A common request is fail over to a local file based realm if an LDAP or database server has gone down allowing administrators to retain access to the server.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JGRP-2398) LOCAL_PING should remove local PingData on stop
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2398?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2398:
---------------------------
Fix Version/s: 4.1.8
> LOCAL_PING should remove local PingData on stop
> -----------------------------------------------
>
> Key: JGRP-2398
> URL: https://issues.jboss.org/browse/JGRP-2398
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.6
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.8
>
>
> {{LOCAL_PING}} does not remove the local node's {{PING_DATA}} from the {{discovery}} map on stop.
> This means when a cluster name is reused, e.g. because we create a new cluster for each method in a test class, the nodes in the new cluster first try to connect to the dead coordinators of the old clusters. With the default {{GMS.max_join_attempts=10}}, this can take a really long time:
> {noformat}
> 13:53:39,024 DEBUG (testng-Test:[]) [GMS] address=Test-NodeA-57106, cluster=org.infinispan.partitionhandling.Test, physical address=127.0.0.1:55320
> 13:53:39,026 TRACE (testng-Test:[]) [GMS] Test-NodeA-57106: discovery took 0 ms, members: 17 rsps (4 coords) [done]
> 13:53:39,026 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: found multiple coords: [054b27e3-9308-65bf-de26-d6cdd4f6bdd3, 6d7f9fb2-f56b-1b88-7f9d-cdee430ac8ca, Test-NodeA-37104, Test-NodeA-8303]
> 13:53:39,026 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: sending JOIN(Test-NodeA-57106) to 6d7f9fb2-f56b-1b88-7f9d-cdee430ac8ca
> 13:53:41,026 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: JOIN(Test-NodeA-57106) sent to 6d7f9fb2-f56b-1b88-7f9d-cdee430ac8ca timed out (after 2000 ms), on try 0
> 13:53:41,026 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: sending JOIN(Test-NodeA-57106) to Test-NodeA-37104
> 13:53:43,026 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: JOIN(Test-NodeA-57106) sent to Test-NodeA-37104 timed out (after 2000 ms), on try 0
> 13:53:43,026 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: sending JOIN(Test-NodeA-57106) to 054b27e3-9308-65bf-de26-d6cdd4f6bdd3
> 13:53:45,027 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: JOIN(Test-NodeA-57106) sent to 054b27e3-9308-65bf-de26-d6cdd4f6bdd3 timed out (after 2000 ms), on try 0
> 13:53:45,027 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: sending JOIN(Test-NodeA-57106) to Test-NodeA-8303
> 13:53:47,027 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: JOIN(Test-NodeA-57106) sent to Test-NodeA-8303 timed out (after 2000 ms), on try 0
> ...
> 13:54:51,036 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: found multiple coords: [054b27e3-9308-65bf-de26-d6cdd4f6bdd3, 6d7f9fb2-f56b-1b88-7f9d-cdee430ac8ca, 0eb381de-3e9a-0320-b2d9-5db3cb39bb34, Test-NodeA-8303]
> 13:54:51,036 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: sending JOIN(Test-NodeA-57106) to 054b27e3-9308-65bf-de26-d6cdd4f6bdd3
> 13:54:53,036 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: JOIN(Test-NodeA-57106) sent to 054b27e3-9308-65bf-de26-d6cdd4f6bdd3 timed out (after 2000 ms), on try 9
> 13:54:53,036 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: sending JOIN(Test-NodeA-57106) to 0eb381de-3e9a-0320-b2d9-5db3cb39bb34
> 13:54:55,037 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: JOIN(Test-NodeA-57106) sent to 0eb381de-3e9a-0320-b2d9-5db3cb39bb34 timed out (after 2000 ms), on try 9
> 13:54:55,037 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: sending JOIN(Test-NodeA-57106) to 6d7f9fb2-f56b-1b88-7f9d-cdee430ac8ca
> 13:54:57,037 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: JOIN(Test-NodeA-57106) sent to 6d7f9fb2-f56b-1b88-7f9d-cdee430ac8ca timed out (after 2000 ms), on try 9
> 13:54:57,037 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: sending JOIN(Test-NodeA-57106) to Test-NodeA-8303
> 13:54:59,037 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: JOIN(Test-NodeA-57106) sent to Test-NodeA-8303 timed out (after 2000 ms), on try 9
> 13:54:59,037 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: too many JOIN attempts (10): becoming singleton
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JGRP-2395) LOCAL_PING fails when 2 nodes start at the same time
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/JGRP-2395?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on JGRP-2395:
------------------------------------
Looks good [~belaban]. I tried the snapshot and parallel start works fine, but I discovered another bug that I'd like fixed in 4.1.8: JGRP-2398.
I wish we could do something similar for production discovery protocols like M/PING though. I know it's a lot more complicated to do it when you don't have up-to-date information about the other nodes, but it's also really surprising when 2 nodes can see each other when they start and they still don't form a single cluster. I guess it's similar to how a node can be included in a view without actually installing the view, and the coordinator just ignores the missing {{VIEW_ACK}}, so I should be already used to it, but it still surprises me when it happens.
> LOCAL_PING fails when 2 nodes start at the same time
> ----------------------------------------------------
>
> Key: JGRP-2395
> URL: https://issues.jboss.org/browse/JGRP-2395
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.6
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.8
>
>
> We have a test that starts 2 nodes in parallel ({{ConcurrentStartTest}} and it is randomly failing since we started using {{LOCAL_PING}}.
> {noformat}
> 01:02:11,930 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: discovery took 3 ms, members: 1 rsps (0 coords) [done]
> 01:02:11,930 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: discovery took 3 ms, members: 1 rsps (0 coords) [done]
> 01:02:11,931 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: could not determine coordinator from rsps 1 rsps (0 coords) [done]
> 01:02:11,931 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: could not determine coordinator from rsps 1 rsps (0 coords) [done]
> 01:02:11,931 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550]
> 01:02:11,931 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550]
> 01:02:11,931 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: I (Test-NodeB-43694) am the first of the nodes, will become coordinator
> 01:02:11,931 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: I (Test-NodeA-29550) am not the first of the nodes, waiting for another client to become coordinator
> 01:02:11,932 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: discovery took 0 ms, members: 1 rsps (0 coords) [done]
> 01:02:11,932 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: could not determine coordinator from rsps 1 rsps (0 coords) [done]
> 01:02:11,932 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550]
> ...
> 01:02:11,941 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: could not determine coordinator from rsps 1 rsps (0 coords) [done]
> 01:02:11,941 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550]
> 01:02:11,941 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: I (Test-NodeA-29550) am not the first of the nodes, waiting for another client to become coordinator
> 01:02:11,942 WARN (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: too many JOIN attempts (10): becoming singleton
> 01:02:11,942 DEBUG (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: installing view [Test-NodeA-29550|0] (1) [Test-NodeA-29550]
> 01:02:11,977 DEBUG (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: created cluster (first member). My view is [Test-NodeB-43694|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> 01:02:11,977 DEBUG (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: created cluster (first member). My view is [Test-NodeA-29550|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> {noformat}
> The problem seems to be that it takes longer for the coordinator to install the initial view and update {{LOCAL_PING}}'s {{PingData}} then it takes the other node to retry the discovery process 10 times.
> In some cases there is no retry, because one node starts slightly faster, but it's not yet coordinator when the 2nd node does its discovery, and both nodes decide they should be coordinator:
> {noformat}
> 01:13:44,460 INFO (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-5386: no members discovered after 3 ms: creating cluster as first member
> 01:13:44,463 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: discovery took 1 ms, members: 1 rsps (0 coords) [done]
> 01:13:44,465 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: could not determine coordinator from rsps 1 rsps (0 coords) [done]
> 01:13:44,465 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: nodes to choose new coord from are: [Test-NodeB-51165, Test-NodeA-5386]
> 01:13:44,466 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: I (Test-NodeB-51165) am the first of the nodes, will become coordinator
> 01:13:44,466 DEBUG (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: installing view [Test-NodeB-51165|0] (1) [Test-NodeB-51165]
> 01:13:44,466 DEBUG (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-5386: installing view [Test-NodeA-5386|0] (1) [Test-NodeA-5386]
> {noformat}
> This second failure mode seems to go away if I move the {{discovery}} map access inside the {{synchronized}} block both in {{findMembers()}} and in {{down()}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFCORE-4603) Replace Deployment --runtime-name option not working
by Romain Pelisse (Jira)
[ https://issues.jboss.org/browse/WFCORE-4603?page=com.atlassian.jira.plugi... ]
Romain Pelisse updated WFCORE-4603:
-----------------------------------
Labels: downstream_dependency (was: )
> Replace Deployment --runtime-name option not working
> ----------------------------------------------------
>
> Key: WFCORE-4603
> URL: https://issues.jboss.org/browse/WFCORE-4603
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 10.0.0.Beta4
> Environment: Red Hat JBoss Enterprise Application Platform (EAP) 7.2 CP 3.
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Priority: Major
> Labels: downstream_dependency
> Fix For: 10.0.0.Beta4, 10.0.0.Final
>
>
> The scenario is that, if you have a deployment to be switched by a new one, the runtime-name property doesn't work the way it should. See the sequence of the commands bellow:
> [standalone@localhost:9990 /] deploy helloworld-rs.war
> [standalone@localhost:9990 /] deploy helloworld-rs-second.war —disabled
> [standalone@localhost:9990 /] :replace-deployment(name=helloworld-rs-second.war,to-replace=helloworld-rs.war,runtime-name=foo.war)
> [standalone@localhost:9990 /] /deployment=helloworld-rs-second.war:read-resource
> {
> "outcome" => "success",
> "result" => {
> "content" => [{"hash" => bytes {
> 0xfe, 0x24, 0x1f, 0xd3, 0x19, 0xa3, 0x72, 0xd4,
> 0xc6, 0xa4, 0x48, 0xe7, 0x8b, 0x9c, 0xc1, 0xd4,
> 0xc7, 0x17, 0xdf, 0xaa
> }}],
> "enabled" => false,
> "name" => "helloworld-rs-second.war",
> "owner" => undefined,
> "persistent" => true,
> "runtime-name" => "helloworld-rs-second.war",
> "subdeployment" => undefined,
> "subsystem" => {
> "undertow" => undefined,
> "ejb3" => undefined,
> "logging" => undefined
> }
> }
> }
> Foo.war is not applied. Looks like it was ignored.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JGRP-2398) LOCAL_PING should remove local PingData on stop
by Dan Berindei (Jira)
Dan Berindei created JGRP-2398:
----------------------------------
Summary: LOCAL_PING should remove local PingData on stop
Key: JGRP-2398
URL: https://issues.jboss.org/browse/JGRP-2398
Project: JGroups
Issue Type: Bug
Affects Versions: 4.1.6
Reporter: Dan Berindei
Assignee: Bela Ban
{{LOCAL_PING}} does not remove the local node's {{PING_DATA}} from the {{discovery}} map on stop.
This means when a cluster name is reused, e.g. because we create a new cluster for each method in a test class, the nodes in the new cluster first try to connect to the dead coordinators of the old clusters. With the default {{GMS.max_join_attempts=10}}, this can take a really long time:
{noformat}
13:53:39,024 DEBUG (testng-Test:[]) [GMS] address=Test-NodeA-57106, cluster=org.infinispan.partitionhandling.Test, physical address=127.0.0.1:55320
13:53:39,026 TRACE (testng-Test:[]) [GMS] Test-NodeA-57106: discovery took 0 ms, members: 17 rsps (4 coords) [done]
13:53:39,026 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: found multiple coords: [054b27e3-9308-65bf-de26-d6cdd4f6bdd3, 6d7f9fb2-f56b-1b88-7f9d-cdee430ac8ca, Test-NodeA-37104, Test-NodeA-8303]
13:53:39,026 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: sending JOIN(Test-NodeA-57106) to 6d7f9fb2-f56b-1b88-7f9d-cdee430ac8ca
13:53:41,026 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: JOIN(Test-NodeA-57106) sent to 6d7f9fb2-f56b-1b88-7f9d-cdee430ac8ca timed out (after 2000 ms), on try 0
13:53:41,026 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: sending JOIN(Test-NodeA-57106) to Test-NodeA-37104
13:53:43,026 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: JOIN(Test-NodeA-57106) sent to Test-NodeA-37104 timed out (after 2000 ms), on try 0
13:53:43,026 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: sending JOIN(Test-NodeA-57106) to 054b27e3-9308-65bf-de26-d6cdd4f6bdd3
13:53:45,027 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: JOIN(Test-NodeA-57106) sent to 054b27e3-9308-65bf-de26-d6cdd4f6bdd3 timed out (after 2000 ms), on try 0
13:53:45,027 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: sending JOIN(Test-NodeA-57106) to Test-NodeA-8303
13:53:47,027 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: JOIN(Test-NodeA-57106) sent to Test-NodeA-8303 timed out (after 2000 ms), on try 0
...
13:54:51,036 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: found multiple coords: [054b27e3-9308-65bf-de26-d6cdd4f6bdd3, 6d7f9fb2-f56b-1b88-7f9d-cdee430ac8ca, 0eb381de-3e9a-0320-b2d9-5db3cb39bb34, Test-NodeA-8303]
13:54:51,036 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: sending JOIN(Test-NodeA-57106) to 054b27e3-9308-65bf-de26-d6cdd4f6bdd3
13:54:53,036 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: JOIN(Test-NodeA-57106) sent to 054b27e3-9308-65bf-de26-d6cdd4f6bdd3 timed out (after 2000 ms), on try 9
13:54:53,036 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: sending JOIN(Test-NodeA-57106) to 0eb381de-3e9a-0320-b2d9-5db3cb39bb34
13:54:55,037 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: JOIN(Test-NodeA-57106) sent to 0eb381de-3e9a-0320-b2d9-5db3cb39bb34 timed out (after 2000 ms), on try 9
13:54:55,037 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: sending JOIN(Test-NodeA-57106) to 6d7f9fb2-f56b-1b88-7f9d-cdee430ac8ca
13:54:57,037 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: JOIN(Test-NodeA-57106) sent to 6d7f9fb2-f56b-1b88-7f9d-cdee430ac8ca timed out (after 2000 ms), on try 9
13:54:57,037 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: sending JOIN(Test-NodeA-57106) to Test-NodeA-8303
13:54:59,037 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: JOIN(Test-NodeA-57106) sent to Test-NodeA-8303 timed out (after 2000 ms), on try 9
13:54:59,037 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: too many JOIN attempts (10): becoming singleton
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months