Skip to content
`gen_cluster` is an erlang behavior for pid clustering. It is a cascading behavior that builds on `gen_server`.
Erlang Ruby
Pull request Compare This branch is 52 commits ahead of jashmenn:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.
ebin
include
priv/tasks
src
test
.gitignore
Emakefile
Makefile
README.mkd
Rakefile
rebar
rebar.config

README.mkd

gen_cluster

Summary

gen_cluster is an erlang behavior for pid clustering. It is a cascading behavior that builds on gen_server.

Status

Early alpha. Feel free to use this in production code as long as you know that nobody else is.

Motivation

Erlang provides many BIFs for dealing with nodes, node clustering, monitoring etc. However, one often wants to build a cluster of processes rather than entire nodes.

This module is a starting point for creating your own gen_server clusters. It aims to deal with common roles, actions, and callbacks one often deals with when making a cluster.

As usual, there are a number of subtleties that crop up when trying to create a cluster. The goal is for gen_cluster to allow one to gloss-over these details and simply provide an easy-to-use foundation for cluster-based erlang projects.

Features

Current features include:

  • Joining a cluster based on a given seed node
  • Storing the list of all current nodes in the cluster
  • Callbacks when a node joins or leaves

Usage

Add the behaviour directive to your module, implement the callbacks for both gen_server and gen_cluster. See example_cluster_srv.erl for full example and function signatures.

-behaviour(gen_cluster).

% gen_server callbacks
-export([init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2, code_change/3]).

% gen_cluster callback
-export([handle_join/3, handle_node_joined/3, handle_leave/4]).

Try it out

Open up three terminals and do the following commands. This will start up three nodes that will join the first node. On q(). of any one of the nodes the other two will see that the node left and update the pidlist accordingly.

# term 1
rake server:start1

# term 2
rake server:start2

# term 3
rake server:start3

# term 2 again
q().

Plans

(features not yet implemented)

  • Globally registered name needs to be taken over by another node if the globally registered node dies. This is an important TODO and will be handled shortly.
  • TCP-layer option, rather than straight distributed erlang
  • Possible integration with Chordjerl

Authors

  • Nate Murray <nmurray [AT] attinteractive.com> github
  • Ari Lerner github
Something went wrong with that request. Please try again.