Skip to content

fixes #124: Reject cluster join when node identifier is already in use#125

Open
guusdk wants to merge 1 commit intoigniterealtime:mainfrom
guusdk:124_Unique-node-identifiers
Open

fixes #124: Reject cluster join when node identifier is already in use#125
guusdk wants to merge 1 commit intoigniterealtime:mainfrom
guusdk:124_Unique-node-identifiers

Conversation

@guusdk
Copy link
Member

@guusdk guusdk commented Feb 18, 2026

With the introduction of static, human-configured node identifiers, identifier uniqueness is no longer guaranteed by randomness (OF-3181).

Before joining a cluster, the local node now checks whether its configured node identifier is already used by an existing cluster member. If a duplicate is detected, the join is refused to prevent multiple nodes from operating with the same identifier.

Additionally, this change causes messages to be logged on standard-out/err when the local node is joining a cluster.

… already in use

With the introduction of static, human-configured node identifiers, identifier uniqueness is no longer guaranteed by randomness (OF-3181).

Before joining a cluster, the local node now checks whether its configured node identifier is already used by an existing cluster member. If a duplicate is detected, the join is refused to prevent multiple nodes from operating with the same identifier.

Additionally, this change causes messages to be logged on standard-out/err when the local node is joining a cluster.
Copy link
Member

@Fishbowler Fishbowler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks sensible, but one open query (accidentally attached to the wrong line, but I don't think the line is even relevant to the question)

for (final Member member : cluster.getMembers()) {
clusterNodesInfo.put(ClusteredCacheFactory.getNodeID(member),
new HazelcastClusterNodeInfo(member, cluster.getClusterTime()));
final NodeID nodeID = ClusteredCacheFactory.getNodeID(member);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do you expect this to behave with 2 booting nodes with the same node ID forming a cluster for the first time?

Does one become the cluster that the other is joining? Or do both reject one another? Is there a difference in terms of how this might affect a production environment?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants