The end of life (EOL) date for this module is on 31 January, 2020.

Node failure

Gateway Connections on Failure

../../ImportedGeneosImages/node_down_dotted.png

When a node in the cluster goes down, Gateway2 connections are automatically redistributed amongst the remaining nodes in the cluster.

For API clients, this will result in an interruption on queries matching data from gateways previously serviced by the old node.

This is communicated via the client ErrorCallback passed to OpenAccess.connect:

Error retreiving DataSet: java.lang.Exception: One of the cluster sources for the stream has gone.
Data from the source has been removed. See cluster logs and monitoring for more information.

Once the connection is re-establish on another node, the client will receive the latest data again.

../../ImportedGeneosImages/spacer.png

API Client Connections on Failure

../../ImportedGeneosImages/node_down_client_dotted.png

When a node goes down, any API clients that are connected to that node automatically reconnect to another node in the cluster.

As above, this results in an interruption of data until the reconnection is complete.

This is again communicated via the ErrorCallback passed to OpenAccess.connect.

If the node to which the user originally connected rejoins the cluster, the client will stay on its current connection rather than being reconnected to the original node.

Since all queries are distributed across all nodes in the cluster, it does not matter to which node the client is connected anyway.

Minimum Number Of Nodes

It is also possible to specify a minimum number of nodes that must exist for the cluster to function. This is useful to ensure there is enough computing power in the cluster to handle the data volume required.

If the number of nodes in the cluster falls below the minimum, configuration changes are rejected. The remaining nodes maintain their gateway connections and still service existing queries from clients.

See Specifying a minimum number of nodes.