JGroups Protocol FD SOCK: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
No edit summary
 
(18 intermediate revisions by the same user not shown)
Line 1: Line 1:
!!!External
=External=


* User Manual FD http://www.jgroups.org/manual/index.html#FD_SOCK
* JGroups Wiki http://community.jboss.org/wiki/JGroupsFDSOCK
* JGroups Wiki http://community.jboss.org/wiki/JGroupsFDSOCK
* http://community.jboss.org/wiki/FDVersusFDSOCK
* http://community.jboss.org/wiki/FDVersusFDSOCK
Line 8: Line 9:
* [[JGroups#Protocols|JGroups]]
* [[JGroups#Protocols|JGroups]]


=Overview=


!!!Overview
FD_SOCK is a failure detection protocol based on opening a direct TCP/IP socket to a neighbor.


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.
=Failure Detection=


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.
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.  


!!!Configuration Sample
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}"/>
     <FD_SOCK start_port="${jboss.jgroups.udp.fd_sock_port:54200}"/>
</pre>


}}}
=VIEW_CHANGE=
 
!!!Recommendations


See [FD_ALL Recommendations|FD_ALL#Recommendations]
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>


__Referenced by:__\\
<pre>
[{INSERT com.ecyrd.jspwiki.plugin.ReferringPagesPlugin WHERE max=20, maxwidth=50}]
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

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

JGroups Events - Failure Detection

Recommendations

FD_ALL 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]