You could monitor the cluster view against the expected number of nodes. In fact, the cache manager transport configuration has a attribute called initial-cluster-size that controls how many expected nodes the view must have for the cache manager to start. You could configure that...
the initial-cluster-size attribute does not solve my problem.
the node that is trying a connect to the cluster coordinator should be able to recognice the failed auth and not starting in standalone mode.
if it continues to run in standalone mode, in fact i get several nodes not building a cluster but hitting the same shared resources (e.g. a relational database) without applying the needed cluster logic.
What version are you using? Did you try latest?
I am using 9.4.4 and 9.4.6.
I want to achieve the following:
- the first node that starts up in the cluster will become the coordinator (so far so good)
- the second node that starts up provides the credentionals to the coordinator
- if the coordinator rejects the node joining request (e.g because of wron credentials), the call "new DefaultCacheManager(...)" should throw an Exception (e.g. wrong credentials provided or similar)
With the current Infinispan implementation i have no possibility to recognice the rejected joining request.
What is the desired behavior when a node could not join an existing cluster?
My expectation is, that either an Exeption will be thrown or a state should be set (like "joining faild)
some more details:
- with SASL i get an SecurityException when the join requests fails, with AUTH not
with AUTH i get
- org.jgroups.protocols.AUTH  - dario-tc8-29119: failed to validate AuthHeader (token: MD5Token) from dario-tc9-45504; dropping message and sending rejection message
- org.jgroups.protocols.pbcast.GMS  - dario-tc8-29119: JOIN(dario-tc8-29119) sent to dario-tc9-45504 timed out (after 5000 ms), on try 9
- org.jgroups.protocols.pbcast.GMS  - dario-tc8-29119: too many JOIN attempts (10): becoming singleton
The main problem here is : "becoming singleton", i would expect that an SecurityException will be thrown.
Solved by setting auth_coord="false" in jgroups.xml