THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Basic definitions
Node - separate instance of Ignite, server or client.
Node order - internal property of each node (in case of TcpDiscoverySpi it is just a uniformly increasing number).
Coordinator - specific (with minimal order) server node responsible for coordinating different processes in the cluster (like verifying discovery messages, managing Partition Map Exchange and others).
Topology - high-level structure all nodes are organized into.
Introduction
Discovery mechanism is the most basic piece of functionality aimed to form a cluster from separate Ignite nodes. Its main goal is to build some view of the cluster (number of nodes, nodes' orders and so on) shared by all nodes and maintain consistency of that view.
Discovery is hidden behind the interface DiscoverySpi, its default implementation is TcpDiscoverySpi. Another implementation is ZookeeperDiscoverySpi but it is out of scope of this article.
DiscoverySpi implementation defines a structure called topology all nodes - both servers and clients - are arranged into. Cluster with TcpDiscoverySpi uses ring-shaped topology.
Ring-shaped topology
Tcp Discovery aligns all server nodes in the cluster into a ring-shaped structure when each node maintains connection to its next and its previous maintains connection to the node. Client nodes stay outside of the ring and are always connected to a specific server (there is no previous node for client, only a server it is connected to).
Most of implementation logic lives in ServerImpl and ClientImpl classes for servers and clients respectively.
Later on "node" will be referring to "server node" for convenience.
When new node starts it tries to find existing cluster probing all addresses provided by TcpDiscoveryIpFinder. If all addresses are unavailable node considers itself as a very first node, forms the cluster from itself and becomes coordinator of this cluster.
If node manages to connect to one of addresses from IpFinder, it starts join process.
Node join process
Overview
Node join consists of several phases involving different messages - join request, NodeAdded message, NodeAddFinished message. During the process new node is validated, configuration information exchange happens if validation was successful and topology information is updated on all nodes.
When node joins successfully it is placed between previous last node and coordinator in the ring.
Join request message
Starting point for join process is joinTopology method presented in both ServerImpl and ClientImpl classes.
At first node collects discovery data from all its components (i.g. it collects cache configurations from GridCacheProcessor). Central point here is TcpDiscoverySpi#collectExchangeData which calls GridComponent#collectJoiningNodeData on each component.
This disco data is packed into join request and sent to the cluster.
When JoinReq reaches coordinator it validates the message and generates NodeAdded message if validation has passed (ServerImpl.RingMessageWorker#processJoinRequestMessage). After that lifecycle of join request is finished; only NodeAdded message is used further. Coordinator creates this message, adds info about joining node (including joining node discovery data from JoinReq) to it and sends across the ring.
NodeAdded message
Processing logic lives in ServerImpl.RingMessageWorker#processNodeAddedMessage.
On receiving NodeAdded each node in cluster (including coordinator node) applies joining node discovery data to components, collects its local discovery data and adds it to the message.
Then node sends NodeAdded to the next node by calling ServerImpl.RingMessageWorker#sendMessageAcrossRing.
Lifecycle of NodeAdded is finished when it completes pass across ring and again reaches coordinator. Coordinator creates NodeAddFinished message and sends it to ring.
NodeAdded message is delivered to the joining node as well, it receives the message at the very end when all other nodes have already processed it.
NodeAddFinished message
NodeAddFinished message as its name suggests finishes the process of node join. On receiving this message each node both server and client fires NODE_JOINED event to notify discovery manager about new joined node.
NodeAddFinished and additional join requests
Joining node will send additional join request if it doesn't receive NodeAddFinished on time. This time is defined by TcpDiscoverySpi#networkTimeout and has a default value of 5 seconds (TcpDiscoverySpi#DFLT_NETWORK_TIMEOUT).
Detecting failed nodes
Section patiently waits for someone to contribute content
Custom discovery messages and events
Section patiently waits for someone to contribute content
Message delivery guarantees
Section patiently waits for someone to contribute content
Overview
Content Tools
Apps
