I’ve added a few missing features to Tribe- Timers and Futures.
Timers provide a way to tell an actor to do something in the future. Tribe supports both one-shot and periodic timers so I believe all the major usage patterns are covered. Adding this feature was fairly easy since all of the low level details are hidden in my Workers gem.
Futures make it easy for an actor to ask another actor to perform an operation and return the result. Previously you would have to use custom events and a lot of boilerplate code to accomplish this. Both synchronous (blocking) and asynchronous (non-blocking) futures are supported. More information on both types can be found in the readme file.
Recently I added a number of features to my Workers gem:
The Task and TaskGroup classes make it even easier to parallelize expensive computations (and blocking IO operations) using background threads. They build on top of worker pools and standardize on various features such as success/failure handling, delayed execution, and arguments.
Parallel Map is syntactic sugar built on top of tasks and task groups. It works very similar to Ruby’s standard Array#map method except each element is mapped in parallel.
Pools are now dynamically resizable. The long term vision for this feature is to experiment with auto-resizing algorithms that adapt to an applications load. In the short term it is mostly useful for quickly changing the size of the default pool (currently set to 20 workers) without having to create a new one.
Recently I put together two new Ruby gems called Tribe EM and Tribe EM AMF Socket. Both gems build on top of my Tribe gem.
Tribe EM bridges the gap between Tribe and EventMachine. Currently it provides basic TCP server functionality for Tribe actors. My intent is to use this as a base for implementing higher-level protocols such as HTTP.
Tribe EM AMF Socket is a wrapper around my existing AMF Socket – Ruby gem. Currently it only supports messages and not requests (RPC). I believe this to be a reasonable limitation for now since AMF Socket messages fit in very well with Tribe’s asynchronous messaging system.
One key difference between the two gems is what I refer to as native vs wrapper implementations:
Native: The Tribe::EM::Connection class is considered native since it pushes the higher level protocol implementation onto the actor threads. This results in greater scalability since actors take advantage of multi-core systems (especially on JRuby).
Wrapper: The Tribe::EM::AmfSocket::Connection class is considered a wrapper since it wraps the AMF Socket gem for use with Tribe. This means that a lot of work (serialization, deserialization, framing, keep alives, etc) are all performed on the EventMachine thread. The result is lower performance than a native implementation, but less coding since I can reuse the existing Ruby implementation of AMF Socket.
Both gem are designed to be easily customized. Feel free to contact me with your custom protocol implementations so that I can add them to the Tribe EM homepage.
Recently I’ve created two new Ruby gems known as Workers and Tribe.
The Workers gem turns low-level operating system threads into simple to use event-driven workers and worker pools. This allows you to focus on message passing instead of complex thread management. As an added bonus, it includes a timer system that can tell your workers to execute work in the future.
The Tribe gem builds on top of Workers in order to implement the actor model. It specifically focuses on event-driven actors such that each thread manages one or more actors. This way the system can support many more actors than is possible with implementations that force a 1:1 thread to actor relationship. A simple benchmark demonstrating one million actors using 20 threads can be found on the performance wiki page.
Both gems have been tested with MRI Ruby 1.9.3 and JRuby 1.7. Due to MRI’s thread limitations, it is highly recommended that you use JRuby if you are concerned about multi-core CPU performance.
Today I hacked together Observation, a simple implementation of the Observer pattern. Inspiration for the API comes from Adobe Actionscript’s event system.
Recently, I created AMF Socket.
AMF Socket is a bi-directional remote procedure call (RPC) system for Adobe Actionscript programs. This library aims to make high quality and free RPC accessible to all of the Flash platforms (web, mobile, and desktop). Using this library you can easily add event driven network functionality to your Flash applications without having to deal with the low level details. High performance and low latency is accomplished through the use of persistent TCP/IP sockets and Flash’s native serialization format (AMF). Due to the use of AMF, you can send primitives, hashes, arrays, and even your custom classes over the network. AMF Socket tries to be the “easy button” for Flash networking by hiding as many details as possible.
I’ve also created a Ruby implementation for the server side. Implementations for other languages should be fairly staright forward and I welcome them. Feel free to contact me if you are interested in creating one.
Today I released a very early/alpha version of Spinal Tap. I deal with a lot of long running Ruby processes (crons, daemons, etc) and I occassionally need to debug them while they are running. Thus Spinal Tap was born. The future vision includes statistics tracking, custom defined commands, and much more. Think of it as a backdoor into your Ruby processes Thanks go to my good friend Scott McCarty for brainstorming the long term vision of the project.