Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Reliable Messaging in Ruby with AP4R

Reliable Messaging in Ruby with AP4R

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.

Rate this Article


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.

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

Community comments

  • Very cool

    by Andrew Kuklewicz,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

    Andrew Kuklewicz

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

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