View Source Partisan Cheatsheet
Configuring Partisan
Partisan is configured using the normal sys.conf
file and/or calling the functions in the partisan_config
module.
Example sys.config file
[
{partisan, [
%% Which overlay to use
{peer_service_manager, partisan_pluggable_peer_service_manager},
%% The listening port for Partisan TCP/IP connections
{peer_port, 10200},
%% The list of channels
{channels, [{data, #{parallelism => 1}]},
%% Encoding for pid(), reference() and names
{pid_encoding, false},
{ref_encoding, false},
{remote_ref_format, improper_list}
]},
%% ...Other apps...
].
Notice that in order to work, all nodes in the cluster need to use the same configuration (apart from parameters like peer_port
which can vary between nodes when deployed on the same host).
Connecting to other peers and sending messages
The following sections assumes you have two nodes running: ruby (ruby@127.0.0.1
) and max (max@127.0.0.1
).
Manually joining using Erlang's console
1. Obtain max's node specification
(max@127.0.0.1)1> NodeSpec = partisan:node_spec().
2. Join ruby with max
(ruby@127.0.0.1)1> NodeSpec = ...
(ruby@127.0.0.1)2> partisan_peer_service:join(NodeSpec).
NodeSpec
is the value obtained at max
in the previous step.
Checking cluster membership view
(max@127.0.0.1)1> partisan:nodes().
Returns [node()]
and should contain both nodes.
Obtain max's shell pid
(max@127.0.0.1)2> partisan:self().
['max@127.0.0.1'|<<"#Pid<0.813.0>">>]
Returns partisan_remote_ref:t()
. Notice this can be a tuple and improper list or a URI binary depending on the configuration option remote_ref_format
which defaults to improper_list
.
Send message from ruby to max
(ruby@127.0.0.1)3> Ref = ['max@127.0.0.1'|<<"#Pid<0.813.0>">>].
(ruby@127.0.0.1)4> partisan:forward_message(Ref, hello).
Check the message arrived at max
(max@127.0.0.1)3> flush().
Shell got hello
ok
Leave the cluster
(max@127.0.0.1)4> partisan_peer_service:leave().
ok
Migrating from Distributed Erlang
In addition to using Partisan-specific functions to manage a cluster and send messages, adopting Partisan implies the need to replace some Erlang BIFs with Partisan's counterparts. This is mainly to cope with the impossibility for Partisan to represent remote pids and references in the way Distributed Erlang does. For that reason, pids and references are encoded manually (or automatically is the configuration options pid_encoding
and ref_encoding
are enabled) using the partisan_remote_ref:from_term/1
function.
Several Erlang BIFs (a.k.a "native implementation") won't work when using Partisan so you will need to use the Partisan API instead. The Partisan API tries to be a dropin replacement to Erlang's as much as possible. It tries comply with Erlang's in terms of naming, function signature and behaviour, so in most cases migrating to Partisan is as easy as replacing the module name from erlang
to partisan
.