Wildfly cluster check using JGroups

[gminog]

Hello,

I was recently handed over to a Wildfly 9.0.1 cluster of 4 standalone nodes.

The standalone conf xml indicates that those nodes join the cluster using the JGroups library implemented by belaban

Based on a great response from rhusar several years ago (see: Re: Discover cluster nodes using jboss_cli or jboss web console? ), one solution for checking which standalone nodes belong to a cluster is by using JGroups Probe.

However, I have encountered a rather unexpected outcome since each node reports a different cluster status. Specifically:

• JGroups Probe execution via node 1 indicates that the cluster has two members: node 1 and node 3.
  • The logs from org.jgroups.protocols.pbcast.NAKACK2 report dropped messages from node 1 (!!) as it allegedly does not belong to the cluster.
• JGroups Probe execution via node 2 indicates that the cluster has one member: node 2.
  • The logs from org.jgroups.protocols.pbcast.NAKACK2 report dropped messages from nodes 1, 3 and 4 as they do not belong to the cluster.
• JGroups Probe execution via node 3 indicates that the cluster has two members: node 1 and node 3.
  • The logs from org.jgroups.protocols.pbcast.NAKACK2 report dropped messages from node 1 (!!) as it allegedly does not belong to the cluster.
• JGroups Probe execution via node 4 indicates that the cluster has one member: node 4.
  • The logs from org.jgroups.protocols.pbcast.NAKACK2 report dropped messages from nodes 1, 2 and 3 as they do not belong to the cluster.

Am I missing something here?

[pferraro]

You can view the cluster membership from any node via the following management CLI command:

/subsystem=jgroups/channel=ee:read-attribute(name=view)

[gminog]

Hello pferraro, thank you for your response!

Could you please elaborate on the exact steps?

[rhusar]

First boot your cluster, then run the jboss-cli.sh (or bat if on windows) and run the following command as shown here:

[rhusar@ribera wildfly-16.0.0.CR1-SNAPSHOT]$ ./bin/jboss-cli.sh -c
[standalone@localhost:9990 /] /subsystem=jgroups/channel=ee:read-attribute(name=view)
{
    "outcome" => "success",
    "result" => "[node2|1] (2) [node2, node1]"
}

This shows the current coordinator, monotonically increasing view ID, number of cluster members, followed by a complete list of cluster members' logical names.

[gminog]

Thank you rhusar !

If I check with the default channel (i.e. channel=ee) then I'm getting a successful outcome.

However,  there is no "result" property in the JSON response.

Is there anything else I should check before concluding that no nodes are connected to the cluster (or no cluster exists at all)?

[rhusar]

If you are not getting any result, it means that the channel is not started. You might be using a different channel or have no deployments that require starting clustering services.