View Source Partisan Cheatsheet
configuring-partisan
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
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
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
Checking cluster membership view
Obtain members
(max@127.0.0.1)1> partisan_peer_service:members().Returns [node_spec()] and should contain both node specifications.
Obtain nodes
(max@127.0.0.1)1> partisan:nodes().Returns [node()] and should contain both nodes.
obtain-max-s-shell-pid
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
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
Check the message arrived at max
(max@127.0.0.1)3> flush().
Shell got hello
ok
leave-the-cluster
Leave the cluster
(max@127.0.0.1)4> partisan_peer_service:leave().
ok
migrating-from-distributed-erlang
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.