JGroups Protocol FD SOCK: Difference between revisions
(Created page with "=Internal= * JGroups") |
|||
| (19 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
=External= | |||
* User Manual FD http://www.jgroups.org/manual/index.html#FD_SOCK | |||
* JGroups Wiki http://community.jboss.org/wiki/JGroupsFDSOCK | |||
* http://community.jboss.org/wiki/FDVersusFDSOCK | |||
=Internal= | =Internal= | ||
* [[JGroups#Protocols|JGroups]] | * [[JGroups#Protocols|JGroups]] | ||
=Overview= | |||
FD_SOCK is a failure detection protocol based on opening a direct TCP/IP socket to a neighbor. | |||
=Failure Detection= | |||
FD_SOCK implements a failure detection protocol based on a ring of TCP sockets created between group members. Each member in a group connects to its neighbor. Last member connects to first, thus forming a ring. Member B is suspected when its neighbor A detects abnormally closed TCP socket presumably due to a node B crash. However, if a member B is about to leave gracefully, it lets its neighbor A know, so that it does not become suspected. | |||
One FD_SOCK disadvantage is that hung servers and/or crashed switches will not cause sockets to be closed. Therefore hung members will not be suspected and network partitions due to switch failures will not be detected. A solution to this problem is to use both [[JGroups Protocol FD|FD]] and FD_SOCK failure detection protocols. | |||
==Also See== | |||
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;"> | |||
:[[JGroups Failure Detection|JGroups Events - Failure Detection]] | |||
</blockquote> | |||
=Recommendations= | |||
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;"> | |||
:[[JGroups Protocol FD_ALL#Recommendations|FD_ALL Recommendations]] | |||
</blockquote> | |||
=Configuration= | |||
JGroups standalone: | |||
<pre> | |||
<FD_SOCK start_port="${jboss.jgroups.udp.fd_sock_port:54200}"/> | |||
</pre> | |||
=VIEW_CHANGE= | |||
FD_SOCK reports view changes in DEBUG mode; this behavior can be quite useful when debugging group membership issues: | |||
<pre> | |||
[2016-02-29 09:25:24,111] [DEBUG] [ {555095}] [org.jgroups.protocols.FD_SOCK] (Cluster Dispatch) -- VIEW_CHANGE received: [host01/tcp, host02/tcp] | |||
</pre> | |||
<pre> | |||
2015-06-17 00:05:16,607 DEBUG [org.jgroups.protocols.FD_SOCK] (Incoming-14,shared=udp) VIEW_CHANGE received: [server24/sr, server12/sr, server09/sr, server26/sr] | |||
</pre> | |||
Latest revision as of 20:21, 8 August 2016
External
- User Manual FD http://www.jgroups.org/manual/index.html#FD_SOCK
- JGroups Wiki http://community.jboss.org/wiki/JGroupsFDSOCK
- http://community.jboss.org/wiki/FDVersusFDSOCK
Internal
Overview
FD_SOCK is a failure detection protocol based on opening a direct TCP/IP socket to a neighbor.
Failure Detection
FD_SOCK implements a failure detection protocol based on a ring of TCP sockets created between group members. Each member in a group connects to its neighbor. Last member connects to first, thus forming a ring. Member B is suspected when its neighbor A detects abnormally closed TCP socket presumably due to a node B crash. However, if a member B is about to leave gracefully, it lets its neighbor A know, so that it does not become suspected.
One FD_SOCK disadvantage is that hung servers and/or crashed switches will not cause sockets to be closed. Therefore hung members will not be suspected and network partitions due to switch failures will not be detected. A solution to this problem is to use both FD and FD_SOCK failure detection protocols.
Also See
Recommendations
Configuration
JGroups standalone:
<FD_SOCK start_port="${jboss.jgroups.udp.fd_sock_port:54200}"/>
VIEW_CHANGE
FD_SOCK reports view changes in DEBUG mode; this behavior can be quite useful when debugging group membership issues:
[2016-02-29 09:25:24,111] [DEBUG] [ {555095}] [org.jgroups.protocols.FD_SOCK] (Cluster Dispatch) -- VIEW_CHANGE received: [host01/tcp, host02/tcp]
2015-06-17 00:05:16,607 DEBUG [org.jgroups.protocols.FD_SOCK] (Incoming-14,shared=udp) VIEW_CHANGE received: [server24/sr, server12/sr, server09/sr, server26/sr]