public
Description: tiny queue system based on starling, in scala
Homepage:
Clone URL: git://github.com/robey/kestrel.git
Steve Jenson (author)
Tue Nov 18 20:47:48 -0800 2008
commit  f1101f698d569693f67265b288480d84b4dcea1a
tree    4a392c2df5b082f6f6526ca6ad37c14d8a4c8727
parent  2afb9b5108470d4c491f7d4c79f7cf11ce3cab7b parent  e7e013f4bfb23cda8293c6375030ed8720ce7215
name age message
file .gitignore Sun Jul 20 20:11:57 -0700 2008 ignore dist. [robey]
file LICENSE Sat May 03 01:44:39 -0700 2008 add license and readme. [robey]
file README.md Tue Nov 18 20:45:53 -0800 2008 correct casing and fixed a misspelled word [Steve Jenson]
directory ant/ Sat Oct 25 21:50:32 -0700 2008 convert to scala-build scripts. [robey]
file build.xml Sun Oct 26 00:32:04 -0700 2008 support per-queue limits on max items and max a... [robey]
directory config/ Sat Nov 01 15:13:59 -0700 2008 add max_journal_size to the config, and change ... [robey]
directory ivy/ Tue Nov 18 20:28:31 -0800 2008 upgrade to configgy 1.2 and use the vscaladoc s... [robey]
file scarling.conf Wed Oct 22 11:35:44 -0700 2008 build rules. [robey]
directory scripts/ Wed Oct 22 11:35:44 -0700 2008 build rules. [robey]
directory src/ Tue Nov 18 20:29:12 -0800 2008 Merge branch 'xacto' [robey]
file tests.xml Sat Nov 08 02:16:41 -0800 2008 add many-clients load test to simulate the envi... [robey]
README.md

Scarling

Scarling is a port of Blaine Cook's "starling" message queue system from ruby to scala: http://rubyforge.org/projects/starling/

In Blaine's words:

Starling is a powerful but simple messaging server that enables reliable distributed queuing with an absolutely minimal overhead. It speaks the MemCache protocol for maximum cross-platform compatibility. Any language that speaks MemCache can take advantage of Starling's queue facilities.

The concept of starling is to have a single server handle reliable, ordered message queues. When you put a cluster of these servers together, with no cross communication, and pick a server at random whenever you do a set or get, you end up with a reliable, loosely ordered message queue.

In many situations, loose ordering is sufficient. Dropping the requirement on cross communication makes it horizontally scale to infinity and beyond: no multicast, no clustering, no "elections", no coordination at all. No talking! Shhh!

Features

Scarling is:

  • fast

It runs on the JVM so it can take advantage of the hard work people have put into java performance.

  • small

Currently about 1K lines of scala (including comments), because it relies on Apache Mina (a rough equivalent of Danger's ziggurat or Ruby's EventMachine) and actors. And frankly because Scala is extremely expressive.

  • durable

Queues are stored in memory for speed, but logged into a journal on disk so that servers can be shutdown or moved without losing any data.

Anti-Features

Scarling is not:

  • strongly ordered

While each queue is strongly ordered on each machine, a cluster will appear "loosely ordered" because clients pick a machine at random for each operation. The end result should be "mostly fair".

  • transactional

Currently when you get an item from a queue, it is removed instantly from that queue and you are responsible for it. If a client crashes after getting at item, it may be lost.

Use

Building from source is easy:

$ ant

Scala libraries and dependencies will be downloaded from maven repositories the first time you do a build. The finished distribution will be in dist.

A sample startup script is included, or you may run the jar directly. All configuration is loaded from scarling.conf.

Performance

All of the below timings are on my 2GHz 2006-model macbook pro.

Since starling uses eventmachine in a single-thread single-process form, it has similar results for all access types (and will never use more than one core).

=========  =================  ==========
# Clients  Pushes per client  Total time
=========  =================  ==========
        1             10,000        3.8s
       10              1,000        2.9s
      100                100        3.1s
=========  =================  ==========

Scarling uses N+1 I/O processor threads (where N = the number of available CPU cores), and a pool of worker threads for handling actor events. Therefore it handles more poorly for small numbers of heavy-use clients, and better for large numbers of clients.

=========  =================  ==========
# Clients  Pushes per client  Total time
=========  =================  ==========
        1             10,000        3.8s
       10              1,000        2.4s
      100                100        1.6s
=========  =================  ==========

Robey Pointer <robeypointer@gmail.com>