[
https://issues.redhat.com/browse/JGRP-2486?page=com.atlassian.jira.plugin...
]
Bela Ban edited comment on JGRP-2486 at 6/26/20 8:08 AM:
---------------------------------------------------------
This wouldn't happen if you used {{UDP}} or {{TCP_NIO2}}. Also, if you disabled the
NIC, TCP itself would block after a while, so what's the use case here?
Note that you could use {{RED}} to drop messages if the queue starts getting full...
The surviving node should suspect and exclude the dead node.
Note that I don't recommend FD, I suggest use FD_ALL2 or FD_ALL3 instead; there have
been some nice improvements in the latter, e.g. skipping the sending of heartbeats if real
traffoc is received etc
was (Author: belaban):
This wouldn't happen if you used {{UDP}} or {{TCP_NIO2}}. Also, if you disabled the
NIC, TCP itself would block after a while, so what's the use case here?
Note that you could use {{RED}} to drop messages if the queue starts getting full...
FD Monitor get stuck on TrasferQueueBundler
-------------------------------------------
Key: JGRP-2486
URL:
https://issues.redhat.com/browse/JGRP-2486
Project: JGroups
Issue Type: Bug
Affects Versions: 4.0.22
Reporter: lukas brandl
Assignee: Bela Ban
Priority: Major
Attachments: Main.java, stack-trace.txt
Apparently there is an issue in the FD protocol. When a cluster nodes is disconnected and
the disconnect isn't handled by FD_SOCK, FD stops sending heartbeats after a while.
This only happens when the queue of the TrasferQueueBundler fills up before the node is
suspected.
The stack trace shows that the FD$Monitor is blocked by the bundler. This is probably the
reason why the heartbeat timeouts are not noticed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)