Enterprise Integration Zone is brought to you in partnership with:

Mitch Pronschinske is the Lead Research Analyst at DZone. Researching and compiling content for DZone's research guides is his primary job. He likes to make his own ringtones, watches cartoons/anime, enjoys card and board games, and plays the accordion. Mitch is a DZone Zone Leader and has posted 2578 posts at DZone. You can read more from them at their website. View Full User Profile

Don't Forget About the Kestrel Messaging Queue

04.08.2013
| 6777 views |
  • submit to reddit
In the messaging queue lineup, the incumbents tend to be ActiveMQ or RabbitMQ and the upstarts who are making headway into the spotlight are usually ZeroMQ or Kafka.  I wanted to remind developers in need of a good messaging architecture to also keep an eye on a queue called "Kestrel" (formerly Scarling).

Eric Lindvall explained  some of he reasons why Kestrel was a perfect fit for Papertrail:

1. Robustness

Using Kestrel (or any system that doesn't require that all messages are held in RAM) protects you from a runaway producer sending too many messages and causing your system to run out of RAM.

2. Flexibility (both infrastructure and code)

The way Resque includes the class to execute along with the "work to be done" makes it very easy to get off the ground. For many cases where what you want done is some piece of code to just get run outside of the web request thread, it solves the problem perfectly.

What you run into when you get into the realm of processing thousands of these pieces of work per second, is that there are often optimizations that you can do to how things are processed.

The changes may include:
 * doing work in batches (it may allow you to cache certain lookups or do things that take round-trips all at once)
 * moving your code from being pushed work to pulling work

Having that separation between "the work" and "the code" can also make it simpler to do things like slowly migrate work from an older way of processing the work to a newer way (to allow you to test how well a newer solution works without needing to do a full deploy).


In that article they also compare Kestrel with Resque, which is based on Redis.  Kestrel would also be easy to modify for Java devs because it's built using Scala.

There are already two great plugins: Kestrel Overall and Kestrel Queue Monitoring.