forked from nivertech/ezk
/
README.txt
117 lines (97 loc) · 4.48 KB
/
README.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
------------------------------------------
||> ezk, the ErlangZooKeeper client <||
------------------------------------------
-------------------------------------------------
||> How to use it
-------------------------------------------------
In the file ezk.app.src 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
ezk:start_connection/0.
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
answering.
-------------------------------------------------
||> 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
zookeeper.
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.
Callbacks:
- 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.