celluloid / floss

UNMAINTAINED: See celluloid/celluloid#779 - A Ruby implementation of the Raft consensus algorithm.

Celluloid is a framework for building asynchronous and multithreaded Ruby programs using object-oriented concepts.

Revival Process Underway

Celluloid is in the process of being refactored and released back into the wild during Google Summer of Code. The next era will not have one individual active maintainer, but a team of collaborators. Going forward, previously dormant maintainer Donovan Keme is returning to support future primary maintainer Emese Padányi during GSoC 2020. Her plan extends past the Summer program, and aims to revive the community and codebase of Celluloid together. Backing this process are Harsh Deep and GSoC alumni Dilum Navanjana. We welcome your collaboration and contributions in this massive work.

The codebase is being refactored to pursue a stable release with no deprecation warnings, and with this cleaned up:

Diagram meticulously developed by Emese Padányi

Proudly supported by the best cloud infrastructure provider in the world: DigitalOcean

Discussion

• Gitter Chat
• Google Group

Documentation

Please see the Celluloid Wiki for more detailed documentation and usage notes.

The following API documentation is also available:

• YARD API documentation
• Celluloid module (primary API)
• Celluloid class methods
• All Celluloid classes

Related Projects

See also: Projects Using Celluloid

• Reel: An "evented" web server based on Celluloid::IO
• DCell: The Celluloid actor protocol distributed over 0MQ
• ECell: Mesh strategies for Celluloid actors distributed over 0MQ
• Celluloid::IO: "Evented" IO support for Celluloid actors
• Celluloid::ZMQ: "Evented" 0MQ support for Celluloid actors
• Celluloid::DNS: An "evented" DNS server based on Celluloid::IO
• Celluloid::SMTP: An "evented" SMTP server based on Celluloid::IO
• nio4r: "New IO for Ruby": high performance IO selectors
• Timers: A generic Ruby timer library for event-based systems

Contributing to Celluloid

• Fork this repository on github
• Make your changes and send us a pull request
• Pull requests will be reviewed for inclusion in the project

License

Copyright (c) 2011-2018 Tony Arcieri, Donovan Keme.

Distributed under the MIT License. See LICENSE.txt for further details.

floss's Issues

Implement persistent storage for local logs.

As per the Raft paper, a node's log should be written to disk so that it can survive machine crashes. This is currently not implemented.

Crashes when not all peers are online on boot

How is this supposed to work with zmq peers? It cannot start when not all peers are online during boot. Which is impossible when you want to start the cluster for the first time.

Why the floss is abandoned?

Why the floss is abandoned? It looks like it's that I need, but gem isn't released yet. Are there any insuperable obstacles on the way further?

A Raft::Node crashes when a RPC times out.

Currently, implementations of Raft::RPC::Client will raise a Raft::TimeoutError if the remote peer does not answer in time. This will crash the client and its caller (most probably the Raft::Node).

Unavailable/-responsive peers should be handled gracefully.

A follower should apply received commands to its FSM

This is not implemented yet.

Transport used by Raft::Node should be configurable.

Currently, the RPC transport is hardcoded to Raft::RPC::ZMQ. A node should take a :transport option to make this configurable.

Raft::Proxy should use Celluloid::ActorProxy

Implement a DCell registry

All current DCell registries depend on a separate service. A floss-based registry would be able to run within each DCell node.

0mq reactor fails sporadically on startup

There seems to be some sort of race condition that makes starting the example distributed hash application fail some of the time.

E, [2013-09-29T19:03:45.233573 #11846] ERROR -- : reactor crashed
Celluloid::ZMQ::DeadWakerError: error sending 0MQ message: Context was terminated
    /Users/jpg/.rvm/gems/ruby-2.0.0-p247/gems/celluloid-zmq-0.15.0/lib/celluloid/zmq/waker.rb:27:in `block in signal'
    /Users/jpg/.rvm/gems/ruby-2.0.0-p247/gems/celluloid-zmq-0.15.0/lib/celluloid/zmq/waker.rb:25:in `synchronize'
    /Users/jpg/.rvm/gems/ruby-2.0.0-p247/gems/celluloid-zmq-0.15.0/lib/celluloid/zmq/waker.rb:25:in `signal'
    /Users/jpg/.rvm/gems/ruby-2.0.0-p247/gems/celluloid-0.15.1/lib/celluloid/evented_mailbox.rb:29:in `<<'
    /Users/jpg/.rvm/gems/ruby-2.0.0-p247/gems/celluloid-0.15.1/lib/celluloid/proxies/sync_proxy.rb:32:in `method_missing'
    /Users/jpg/.rvm/gems/ruby-2.0.0-p247/gems/celluloid-0.15.1/lib/celluloid/proxies/actor_proxy.rb:20:in `_send_'
    /Users/jpg/.rvm/gems/ruby-2.0.0-p247/gems/celluloid-0.15.1/lib/celluloid.rb:185:in `new'
    /Users/jpg/src/floss/lib/floss/node.rb:74:in `run'
    /Users/jpg/.rvm/gems/ruby-2.0.0-p247/gems/celluloid-0.15.1/lib/celluloid/calls.rb:25:in `public_send'
    /Users/jpg/.rvm/gems/ruby-2.0.0-p247/gems/celluloid-0.15.1/lib/celluloid/calls.rb:25:in `dispatch'
    /Users/jpg/.rvm/gems/ruby-2.0.0-p247/gems/celluloid-0.15.1/lib/celluloid/calls.rb:122:in `dispatch'
    /Users/jpg/.rvm/gems/ruby-2.0.0-p247/gems/celluloid-0.15.1/lib/celluloid/actor.rb:322:in `block in handle_message'
    /Users/jpg/.rvm/gems/ruby-2.0.0-p247/gems/celluloid-0.15.1/lib/celluloid/actor.rb:416:in `block in task'
    /Users/jpg/.rvm/gems/ruby-2.0.0-p247/gems/celluloid-0.15.1/lib/celluloid/tasks.rb:55:in `block in initialize'
    /Users/jpg/.rvm/gems/ruby-2.0.0-p247/gems/celluloid-0.15.1/lib/celluloid/tasks/task_fiber.rb:13:in `block in create'
E, [2013-09-29T19:03:45.234468 #11846] ERROR -- : reactor crashed

Implement log compaction

See:

https://ramcloud.stanford.edu/wiki/download/attachments/12386595/compaction.pdf?version=1&modificationDate=1367123151531

Add an acceptance test suite for cluster behavior.

The behavior of a cluster should be tested for scenarios such as random node failure.

Opensource this!

We had a good talk about Raft and think this should be open-sourced!
More people would love to help out!

When attempting to use RubyProf RPCs time out and this causes ripple on failures.

E, [2013-09-30T04:07:52.989930 #80319] ERROR -- : Actor crashed!
NoMethodError: undefined method `-' for nil:NilClass
    /Users/jpg/src/floss/lib/floss/log_replicator.rb:98:in `replicate'
    /Users/jpg/src/floss/lib/floss/log_replicator.rb:58:in `block (2 levels) in initialize'
    /Users/jpg/.rvm/gems/ruby-1.9.3-p448/bundler/gems/celluloid-11fe1990fd6e/lib/celluloid/actor.rb:398:in `block in task'
    /Users/jpg/.rvm/gems/ruby-1.9.3-p448/bundler/gems/celluloid-11fe1990fd6e/lib/celluloid/tasks.rb:55:in `block in initialize'
    /Users/jpg/.rvm/gems/ruby-1.9.3-p448/bundler/gems/celluloid-11fe1990fd6e/lib/celluloid/tasks/task_fiber.rb:13:in `block in create'

I am not sure what is causing this yet but I saw it during testing.

Allow for cluster membership changes.

The current code only implements statically configured clusters. Cluster membership changes are described in Section 6 of the Raft paper.

User should not have to call Node#run himself.

As per 6fd9f82#L0R56, #run should be called asynchronously in the initializer.

A candidate should retry the RPC if a peer does not respond to the vote request.

During election, a candidate sends vote requests to all other peers. If the RPC fails or times out, the candidate should retry.

Implement Node#wait_until_ready: Sleep until the node completed its start-up.

See 6fd9f82#L0R60. Probably a good place to use Celluloid::IO::Stream::Latch again.

Raft::Proxy must pass the replicated FSM to the node.

The node is to apply replicated log entries to the FSM, but currently the FSM is not attached to the Raft::Node.

Extract latches into Celluloid itself?

See also celluloid/celluloid-io#89

The latches defined here:

https://github.com/celluloid/floss/blob/master/lib/floss/count_down_latch.rb
https://github.com/celluloid/floss/blob/master/lib/floss/latch.rb

...are potentially generally useful. Should we extract them into Celluloid?