Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Clone this wiki locally
We're considering applying for Google Summer of Code 2013! The deadline is 29 March at 19:00 UTC.
Leader Election/Services for DCell
The zk gem implements a (semi-)robust leader election protocol that works on top of Zookeeper. This can be leveraged to allow you to run the same DCell service on multiple nodes and have those services elect a leader that can be used for any behavior that requires coordination
Gossip/Paxos for DCell
We tried this before, but it didn't work out. I would love for someone to pick it up again! This would be an in-process replacement for Zookeeper in the above context like we had before, that could be used as an alternative in environments where Zookeeper is seen as an onerous dependency
JRuby "Turbo Mode"
JRuby runs on the excellent JVM platform which provides a number of high performance lock-free/wait-free data structures that could be used to significantly improve Celluloid's performance on these platforms. Celluloid also makes it quite easy to swap out things like mailboxes which are presently Celluloid's main bottleneck.
Celluloid could support some JRuby-specific optimizations and utilize better data structures for communicating between actors (e.g. ArrayBlockingQueue, LinkedTransferQueue, Disruptor)
Typesafe Console Clone
A dashboard of your entire Celluloid system, ala http://typesafe.com/products/console
Circuit Breaker implementation
Design and spike out Lattice, a Celluloid-based web framework, and example apps. Ideas should be taken from other actor-based web frameworks, including the Nitrogen framework on Erlang, and the Play/Spray frameworks on Scala. This could form the basis of, or be extracted from, the Celluloid console implementation.
Take the combined ideas of Erlang and Akka towards a supervision model for Celluloid. Several large issues have been raised with the flexibility of supervision and pooling. The goal would be to have a solid solution for system and user level actors within Celluloid.
One thread per actor often results in a lot of threads. If your actors aren't very busy, you've got a lot of threads not doing anything. If those actors were to be assigned to a dynamically sized thread pool, they could perhaps be more efficient about their thread usage if they're not so busy. This would hopefully reduce the amount of time the kernel spends juggling those threads across cores.
In systems with complex interaction between Actors, it is possible for deadlocks to occur. This is particularly true when using the
exclusive feature to force in-order processing of messages. Finding and debugging these deadlocks is very difficult. Creating a "deadlock detector" thread or providing more robust logging would be very useful for solving these issues when they arise.
Asynchronous integration testkit
Current state of the art is to send messages, loop to check and timeout or sleep and then check stuff. Would be great to provide asynchronous expectations kit, ala
expectMsg in Akka: