[ https://issues.jboss.org/browse/JGRP-2387?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2387 at 10/3/19 9:13 AM: --------------------------------------------------------- The technical detail: FD_ALL keeps track of the time the last message from each member was seen in the "timestamps" map. It periodically suspects any entries in this map whose timestamps are too old. When a new view is installed, any members that left are removed from the map, and an entry is added for each member if it doesn't already exist. When any FD_ALL message is received from a member its entry in "timestamps" is updated. If msg_counts_as_heartbeat is on then the same is done for every message from that member. (this is off by default) The problem: When it updates the timestamp, no membership check is done first. So a message from a non-member triggers an entry added to the table, which is never removed until the next view is processed, and will continually send suspect events up the stack. This triggers VERIFY_SUSPECT to try to ping it, which it can't because it doesn't have the address (but can cause a "no physical address" log in some cases). VERIFY_SUSPECT will eventually send SUSPECT events up the stack, which are ignored by GMS because the node isn't part of the cluster. was (Author: dereed): The technical detail: FD_SOCK keeps track of the time the last message from each member was seen in the "timestamps" map. It periodically suspects any entries in this map whose timestamps are too old. When a new view is installed, any members that left are removed from the map, and an entry is added for each member if it doesn't already exist. When any FD_SOCK message is received from a member its entry in "timestamps" is updated. If msg_counts_as_heartbeat is on then the same is done for every message from that member. (this is off by default) The problem: When it updates the timestamp, no membership check is done first. So a message from a non-member triggers an entry added to the table, which is never removed until the next view is processed, and will continually send suspect events up the stack. This triggers VERIFY_SUSPECT to try to ping it, which it can't because it doesn't have the address (but can cause a "no physical address" log in some cases). VERIFY_SUSPECT will eventually send SUSPECT events up the stack, which are ignored by GMS because the node isn't part of the cluster. -- This message was sent by Atlassian Jira (v7.13.8#713008)