Skip to content
Fetching contributors…
Cannot retrieve contributors at this time
118 lines (97 sloc) 4.48 KB
||> ezk, the ErlangZooKeeper client <||
||> How to use it
In the file are the standard server
addresses. You have to replace these with your
own. They are in the format {Ip, Port, Timeout, Heartbeat}.
Then you can use it by starting the application ezk.
A Connection can be established by calling
A list of all Commands can be found by using ezk:help/0.
||> Blocking and Non Blocking Commands
The normal set of commands is blocking, that means, that
if you call them you need to wait for the answer before
going on.
Now there is a second set of commands, which start with
the prefix n_ and are non blocking. The have two additional
parameters: A Pid and a Tag. If the reply to the command
is determinded the Client will send the answer as {Tag, Reply}
to the given PId. Its similar to the usage of watches.
The n_ commands are not fully tested and therefor marked as
experimental. Commands which set watches are not already
available in a n_ version.
Using the n_ versions you have to be a little aware of the load.
If you have 1000 processes which send 1000 ls requests to the
server there is not a problem and the server has to deal
with at most 1000 messages at one time. But if you use the
n_ls there is 1.000.000 messages which may all arive before
it can answer even the first. This may lead to a delay in
||> Differences from the Java ZooKeeper Client
- Watches:
If you set a watch you specify a WatchOwner
and a WatchMessage as parameters. When the
Watch is triggered the Watchowner (a PId)
gets a Message of the format:
{WatchMessage, {WatchedPath, WatchTyp, SyncCon}}.
Or, if the Client loses Connection
{watchlost, WatchMessage, Watchdata}.
- Connections:
A running ezk can handle multiple connections.
This makes it easier to handle different sets of
epheremal nodes and makes it possible to let one
connection, and therefore all epheremal nodes created
with it, die without touching other processes using
A connection can get bound to one or more PIds by
using ezk.add_monitors/2 or provide a list of PIds
when establishing the connection (using
ezk:start_connection/1). Those processes are then
monitored and if one dies the connection is ended.
- Parallel:
The Client is ready to handle a high amount
of parallel requests from different Processes.
- Highlander:
A behaviour. For further information... scroll down.
||> Things not included
Quotas are not included in this Client.
||> Highlander
The Highlander, or to be more precise the ezk_highlander, is
a behaviour. You give it a list of ZK Nodenames (which are
not already taken) and a module. Then you start a lot of
instances of the highlander (on different machines would be
the normal usecase) and the highlander makes sure there is at
most one instance per path running and if one fails it is
directly replaced by another instance.
- init/2
Gets the Path the highlander got highlander in and the Arguments
which were given to the start_link function when starting
the highlander.
Should start all necessary processes and then return an
intern state which is later given to the terminate function
- terminate/2
Called when the highlanders time is running out.
Gets the intern state and the Reason of termination
- motto/1
This function is called evereytime the highlanderwannabe
trys to get highlander in a path.
Gets the path the highlander trys to get highlander in. Should
return the data the highlander stores in his node. This is
the motto which is read by the no_quickening.
- no_quickening/2
This function is called every time the highlanderwannabe tryed
to get a highlander but failed. It gets the path the wannabe
wanted to get highlander in and the motto of the one who is the
actual highlander in this part. The returnvalue is ignored.
Something went wrong with that request. Please try again.