JGroups Protocol VERIFY SUSPECT: Difference between revisions

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


Verifies that a suspected member is really dead by pinging that member once again. Drops suspect message if member does respond. Tries to minimize false suspicions.  
VERIFY_SUSPECT is a protocol that checks a suspected member.


The protocol works as follows: it catches SUSPECT events traveling up the stack. Verifies that the suspected member is really dead. If yes, passes SUSPECT event up the stack, otherwise discards it. Has to be placed somewhere above the [FD] layer and below the [GMS] layer (receiver of the SUSPECT event). Note that SUSPECT events may be reordered by this protocol.
=Suspect Verification=


VERIFY_SUSPECT verifies that a suspected member is really dead by pinging that member once again. If the member responds, it drops the SUSPECT message. Tries to minimize false suspicions.


!!!Configuration Sample
The protocol works as follows: it catches SUSPECT events traveling up the stack:


{{{
<pre>
 
2016-02-29 09:25:22,487 [TRACE] [org.jgroups.protocols.VERIFY_SUSPECT] (Cluster Dispatch) -- verifying that host02/tcp is dead
    <VERIFY_SUSPECT timeout="1500"/>
</pre>


}}}
Verifies that the suspected member is really dead. If yes, passes SUSPECT event up the stack:


!!!Periodic Scans
<pre>
2016-02-29 09:25:24,001 [TRACE] [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,TEST-CLUSTER,host01/tcp) -- host02/tcp is dead (passing up SUSPECT event)
</pre>
 
If the member responds, VERIFY_SUSPECT discards the SUSPECT event.
 
VERIFY_SUSPECT  must be placed somewhere above the [[JGroups Failure Detection|failure detection layer]] and below the [[JGroups Protocol GMS|GMS]] layer (receiver of the SUSPECT event). Note that SUSPECT events may be reordered by this protocol.
 
==Periodic Scans==


VERIFY_SUSPECT starts an internal thread ("VERIFY_SUSPECT.TimerThread") when a suspect is added to the suspect table. The thread continually iterates over the entries and removes entries whose time have elapsed. For each removed entry, a SUSPECT event is passed up the stack (because elapsed time means verification of member's liveness failed). Computes the shortest time to wait (min of all timeouts) and waits(time) ms. Will be woken up when entry is removed (in case of successful verification of that member's liveness). Terminates when no entry remains in the table.
VERIFY_SUSPECT starts an internal thread ("VERIFY_SUSPECT.TimerThread") when a suspect is added to the suspect table. The thread continually iterates over the entries and removes entries whose time have elapsed. For each removed entry, a SUSPECT event is passed up the stack (because elapsed time means verification of member's liveness failed). Computes the shortest time to wait (min of all timeouts) and waits(time) ms. Will be woken up when entry is removed (in case of successful verification of that member's liveness). Terminates when no entry remains in the table.


=Configuration=


 
<pre>
__Referenced by:__\\
  <VERIFY_SUSPECT timeout="1500"/>
[{INSERT com.ecyrd.jspwiki.plugin.ReferringPagesPlugin WHERE max=20, maxwidth=50}]
</pre>

Latest revision as of 03:30, 3 March 2016

External

Internal

Overview

VERIFY_SUSPECT is a protocol that checks a suspected member.

Suspect Verification

VERIFY_SUSPECT verifies that a suspected member is really dead by pinging that member once again. If the member responds, it drops the SUSPECT message. Tries to minimize false suspicions.

The protocol works as follows: it catches SUSPECT events traveling up the stack:

2016-02-29 09:25:22,487 [TRACE] [org.jgroups.protocols.VERIFY_SUSPECT] (Cluster Dispatch) -- verifying that host02/tcp is dead

Verifies that the suspected member is really dead. If yes, passes SUSPECT event up the stack:

2016-02-29 09:25:24,001 [TRACE] [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,TEST-CLUSTER,host01/tcp) -- host02/tcp is dead (passing up SUSPECT event)

If the member responds, VERIFY_SUSPECT discards the SUSPECT event.

VERIFY_SUSPECT must be placed somewhere above the failure detection layer and below the GMS layer (receiver of the SUSPECT event). Note that SUSPECT events may be reordered by this protocol.

Periodic Scans

VERIFY_SUSPECT starts an internal thread ("VERIFY_SUSPECT.TimerThread") when a suspect is added to the suspect table. The thread continually iterates over the entries and removes entries whose time have elapsed. For each removed entry, a SUSPECT event is passed up the stack (because elapsed time means verification of member's liveness failed). Computes the shortest time to wait (min of all timeouts) and waits(time) ms. Will be woken up when entry is removed (in case of successful verification of that member's liveness). Terminates when no entry remains in the table.

Configuration

   <VERIFY_SUSPECT timeout="1500"/>