Chapter 5. Writing Monitor Nodes
Prev |  | Next

## Chapter 5. Writing Monitor Nodes

So far in this book we have mostly discussed electable nodes, which are by definition nodes that have access to a JE ReplicatedEnvironment. However, replication groups can include any number of nodes that cannot be elected Master, because they have no access to the JE replicated environment in use by the replication group.

These type of non-electable nodes are usually called monitor nodes. The point of a monitor node is to allow a process to have some understanding of the replication group's structure such as which node is the Master and what nodes belong to the group as Replicas. Monitor nodes also have the ability to know when certain events have happened in the replication group, such as when a new Master is elected or when new nodes are added to, or deleted from, the group.

There are many uses for Monitor nodes, starting with the ability to write processes that monitor the current status of your HA application. But another, arguably more interesting, use for Monitor nodes is for request routing. As we have explained earlier in this book, Replicas can only service read-only requests; all write requests must occur on the Master. However, Replicas are only capable of noticing that they have been asked to process a write request. At most, out of the box, they can complain about it by throwing a ReplicaWriteException, and then completely rejecting the request.

One way to handle this problem is by writing an request router that sits on your network between the electable nodes and your clients. This router can send write requests to the Master, and read requests to the Replicas. A robust example of this sort of thing could also perform load balancing across the various Replicas, so that no one Replica becomes swamped by too many read requests.

## Monitor Class

You implement Monitor nodes using the Monitor class. The `Monitor` class allows you to obtain information about the replication group, such as its name, where the Master is, and other such information. The `Monitor` class also allows you to run an event listener that can alert you to changes in the composition of the replication group.

You instantiate a `Monitor` class object in much the same way as you instantiate a ReplicatedEnvironment class object. It is necessary to give the node a name, to indicate that it is a Monitor node, to identify the node's host and port information, and to identify helper hosts. You use a ReplicationConfig object to do these things, just as you do when instantiating a ReplicatedEnvironment object.

Once the `Monitor` object has been instantiated, it must be registered at least once with the Master so that the replication group will know to keep the node informed about changes in the group composition. (Subsequent attempts to register the node are simply ignored by the Master.) You use the Monitor.register() method to register a Monitor node with a Master.

For example:

     // Initialize the monitor node config
     ReplicationConfig config = new ReplicationConfig();
     config.setGroupName("MyRepGroupName");
     config.setNodeName("mon1");
     config.setNodeType(NodeType.MONITOR);
     config.setNodeHostPort("monhost1.acme.com:7000");
     config.setHelperHosts("node1.acme.com:5000,node2.acme.com:5000");

     Monitor monitor = new Monitor(config);

     // If the monitor has not been registered as a member of the
     // group, register it now. register() returns the current node
     // that is the master.
     ReplicationNode currentMaster = monitor.register();

Prev |  | Next
Converting Existing Environments for Replication | Home | Listening for Events