Skip to content
ZK client for EventMachine-based applications
Failed to load latest commit information.
.dev_extras switch to 1.9.3 by default
lib bump version to 1.0.2, releaseops version
releaseops @ 0d1bcf4 bump version to 1.0.2, releaseops version
spec upgrade to zk 1.6.1, add a bunch of related stuff
.gitignore improve rakefile, add bundler optimizations for mb:test_all
.gitmodules add releaseops to zk-eventmachine
.yardopts refactor stuff to use Deferred::Accessor, add Rake tasks for testing …
Gemfile upgrade to zk 1.6.1, add a bunch of related stuff
Guardfile upgrade to zk 1.6.1, add a bunch of related stuff
LICENSE add readme and license
README.markdown more README
Rakefile ok, don't test against rubinius, i don't have the patience



ZKEventMachine is a ZK client implementation for EventMachine for interacting with the Apache ZooKeeper server. It provides the core functionality of ZK, but in a single-threaded context with a callback-based API. It is tested on JRuby, and MRI versions 1.8.7 and 1.9.2. Rubinius 1.2.x should work, but support should be considered experimental at this point (if you find a bug, please report it, and I'll do my best to fix it).


Installation via rubygems is recommended, as there are a few dependencies.

$ gem install zk-eventmachine

This will install ZK and slyphon-zookeeper (as a side note, for experimentation in irb, it's probably easier to use ZK due to its synchronous nature).


Connections are easy to set up, and take the same host string argument that the ZK and Zookeeper use.

# a connection to a single server:

zkem ="localhost:2181")

zkem.connect do
  # the client is connected when this block is called

Note: at the moment, the chroot-style syntax is iffy and needs some attention.

Closing a connection should be done in the same style, by passing a block to the close method.

zkem.close do
  # connection is closed when this block is called

Due to the way that the underlying slyphon-zookeeper code is written, it is important that you not stop the reactor until the on_close callback has fired (especially when using epoll on linux). Strange things may happen if you do not wait for the connection to be closed!


ZKEventMachine was written so that every call can handle two callback styles. The first is node-js style:

zkem.get('/') do |exception,value,stat|

In this style, the first value returned to the block is an Exception object if an error occured, or nil if the operation was successful. The rest of the arguments are the same as they would be returned from the synchronous API.

The second style uses EventMachine::Deferrable (with a few slight modifications), and allows you to add callbacks and errbacks (in something approximating Twisted Python style).

d = zkem.get('/')

d.callback do |value,stat|
  # success

d.errback do |exc|
  # failure

The callback/errbacks return self, so you can chain calls:

zkem.get('/').callback do |value,stat|

end.errback do |exc|


Also provided is an ensure_that method that will add the given block to both callback and errback chains:

# the goalposts |*| below are so that the block can take any number of
# args, and ignore them

zkem.get('/').ensure_that do |*|
  # clean up 

Example Usage



ZKEventMachine is developed and maintained by Jonathan Simms and Topper Bowers. The HP Development Corp. has graciously open sourced this project under the MIT License, and special thanks go to Snapfish who allowed us to develop this project.

Something went wrong with that request. Please try again.