Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Erlang-Bindings for Zookeeper
branch: master

This branch is 118 commits behind campanja:master

Fetching latest commit…

Cannot retrieve the latest commit at this time

Failed to load latest commit information.


||>   ezk, the ErlangZooKeeper client  <||

||>   How to use it
First you have to replace the ZK Server Ips in the with the IPs of your own ZooKeeper server.
Then the client is started like every app. The name of 
the app  is "ezk".

A list of all Commands can be found by using ezk:help().

||>    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}.

- Parallel: 
  	   The Client is ready to handle a high amount 
	   of parallel requests from different Processes.

- Zookeeper:
           A behaviour. For further information... scroll down.

- Because the ezk is a application on it's own there are some
           issues concerning the epheremal nodes. If a process
           dies unexpected which hast set a epheremal node the
	   node is not erased by zookeeper unless the process
	   eas linked to ezk which then also dies and kills the 
	   connection to the zookeeperserver. 
	   --> Perhabs the ezk is refactored to allow every 
	   process to get it's own ezk.

||>    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.
Something went wrong with that request. Please try again.