[jboss-jira] [JBoss JIRA] (JGRP-2451) FD_ALL3: improvements over FD_ALL
Bela Ban (Jira)
issues at jboss.org
Wed Mar 4 01:33:24 EST 2020
[ https://issues.redhat.com/browse/JGRP-2451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13973223#comment-13973223 ]
Bela Ban edited comment on JGRP-2451 at 3/4/20 1:32 AM:
--------------------------------------------------------
Further improvements:
* Dont' send heartbeat to self
* Skip setting timestamp on reception of a heartbeat message from self
* Skip checking heartbeat from self
was (Author: belaban):
Further improvements:
* Dont' send heartbeat to self
* Skip setting timestamp on reception of a heartbeat message from self
* Skip checking heartbeat from self
* Re-introduce {{timeout_check_interval}}?
** If we have a timeout of 60s, and a member sends a heartbeat just after the 60s-period started, we won't suspect it until roughly 120s later
** Perhaps document this behavior and reduce the default to {{30s}}. Suspicions would happen in the range {{[30..60]}}
> FD_ALL3: improvements over FD_ALL
> ---------------------------------
>
> Key: JGRP-2451
> URL: https://issues.redhat.com/browse/JGRP-2451
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0, 4.2.1
>
>
> Improvements to {{FD_ALL}}.
> * Messages should count as heartbeats ({{msg_counts_as_heartbeat}} should be *default*, and as such, deprecated/removed).
> * When a multicast message is sent before {{interval}} elapsed, we suppress sending a heartbeat
> It is crucial that setting the in the map is quick, especially since this is done on every message. This should not be an issue, as we fetch the current time from the time service, which does *not* call {{System.nanoTime()}} or {{System.currentTimeMillis()}} every time.
> The advantage is that we only send heartbeats when there is no (multicast) traffic, and we don't suspect a member P when heartbeats have been missing despite receiving traffic from P.
> We need to think about whether to consider unicast messages, too, on the sender side: we could populate a bit map with messages sent to members: on a unicast message to P, P's bit would be set in the bit. On a multicast message, all bits would be set. Then, we could selectively send heartbeats only to members with bits set to 0.
> However, this is only feasible with sending a message N-1 times (e.g. TCP); for UDP we don't have such an 'anycast' available.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
More information about the jboss-jira
mailing list