BT

Reliable Messaging in Ruby with AP4R

by Sebastien Auvray on Jun 18, 2007 |
Shun'ichi Shinohara and Kiwamu Kato have been  working on bringing reliable messging to Ruby with their own API & protocol project, based on previous experiences designing a Java-based high volume messaging framework.   AP4R, Asynchronous Processing for Ruby, is an implementation of reliable asynchronous message processing, providing message queuing and message dispatching.  Shun'ichi and Kiwamu gave a presentation at RubyKaigi 2007(pdf slides) about their API emphasizing it's key design philosophies: Robustness and Lightweight.

The project is just a year old, and already supports:
  1. Business logic can be implemented as simple Web apps or ruby code, whether it's called asynchronously or synchronously.
  2. RBMS (MySQL) or file-based message persistance
  3. Load balancing over multiple AP4R processes on single/multiple server(s) is supported.
  4. Multiple protocol support: XML-RPC, SOAP, HTTP POST, and more.
Shun'ichi and Kiwamu had previously implemented their own Java-based API and protocol (called RtFA), which was used in a large app with 100 servers processing over 100 million messages a day. Shun'ichi and Kiwamu claim to have improved upon their previous work with AP4R, while also focusing on on the ease of use. AP4R comes with a comprehensive documentation.

Integrated into rails, a typical process flow for using AP4R is:
  1. A client(e.g. a web browser) makes a request to a web server (Apache, Lighttpd, etc...).
  2. A rails application is synchronously executed on mongrel via mod_proxy or something.
  3. Rails app sends a message via AP4R APIs and can then immediatley respond to the client.
  4. AP4R queues the message and requests it to the web server asynchronously.
  5. The asynchronous business logic, implemented as usual rails action, is executed.
The focus for 0.3.x was Daemonization, URL-rewrite filter, DLQ / SAF recovery, and support for Stomp and HTTP has underlying protocols. Future versions will include support for Monitoring & management (e.g. thread status, web frontend), Coordination with Cacti, Nagios, etc, multi-process, Dynamic configurability, Automatic recovery, Blocking queues, and more.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Very cool by Andrew Kuklewicz

kudos to the ap4r folks, great to see this project coming along.

Nice to see more messaging interest in rails - and the reliable messaging ruby lib + drb is a great way to get something going using good existing solutions.

For an alternative, folks might also want to look at activemessaging
Here's an intro on infoq about it

Cheers,
Andrew Kuklewicz

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT