[
https://issues.redhat.com/browse/JGRP-2461?page=com.atlassian.jira.plugin...
]
Robert Mitchell edited comment on JGRP-2461 at 3/16/20 5:17 PM:
----------------------------------------------------------------
We have chosen the following workarounds to deal with this:
# Placing all of our possible nodes into the initial hosts for TCPPING and setting the
max_dynamic_hosts value to 0. Note that this works for us because we manage the possible
nodes for our cluster outside of JGroups.
# Reduce the {conn_close_timeout} timeout setting on UNICAST3 to 30 seconds. The default
4 minutes was just a little long in some edge cases (and especially when testing the
clustering). This allows even very quick outages to be unlikely to see this issue (our
node restart time is almost always over 30 seconds).
was (Author: bjetal2003):
We have chose the following workarounds to deal with this:
# Placing all of our possible nodes into the initial hosts for TCPPING and setting the
max_dynamic_hosts value to 0. Note that this works for us because we manage the possible
nodes for our cluster outside of JGroups.
# Reduce the {conn_close_timeout} timeout setting on UNICAST3 to 30 seconds. The default
4 minutes was just a little long in some edge cases (and especially when testing the
clustering). This allows even very quick outages to be unlikely to see this issue (our
node restart time is almost always over 30 seconds).
Clustering can fail when re-adding an existing node using TCP_NIO2
------------------------------------------------------------------
Key: JGRP-2461
URL:
https://issues.redhat.com/browse/JGRP-2461
Project: JGroups
Issue Type: Bug
Affects Versions: 4.1.8
Reporter: Robert Mitchell
Assignee: Bela Ban
Priority: Major
When a node leaves a cluster and then later attempts to re-enter, a race condition can
occur where the clustering fails to occur. Here is the sequence of events that seems to
allow this to occur:
# The rejoining node must have a "higher" IP address than the current cluster
coordinator.
# On the rejoin attempt, the coordinator sends a message to the rejoining node before the
rejoining node sends to the coordinator using its prior address. I have seen this happen
for two reasons:
## UNICAST3 is resending messages (which often happens with the final LEAVE_RSP from the
prior cluster membership because it apparently does not get acked before the connection
closes)
## TCPPING is sending a ping request to the cached prior address.
# The connection gets established. It will then be used by the rejoining node whenever
communicating with the cluster coordinator.
# However, the cluster coordinator has this as the connection for the prior address. So
the following happens whenever it wants to send a message to the rejoining node:
## It will attempt to create a new connection.
## The rejoining node will reject the connection as a redundant connection with its
current connection taking precedence since it is coming from the same logical address as
the "bad" connection.
Since the messages needed to find and join the cluster or merge the two clusters are all
unicast messages, the rejoining node will never get them and not be able to join until
something happens that causes the initial connection to get closed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)