Reliable Messaging in Ruby with AP4R
The project is just a year old, and already supports:
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.
- Business logic can be implemented as simple Web apps or ruby code, whether it's called asynchronously or synchronously.
- RBMS (MySQL) or file-based message persistance
- Load balancing over multiple AP4R processes on single/multiple server(s) is supported.
- Multiple protocol support: XML-RPC, SOAP, HTTP POST, and more.
Integrated into rails, a typical process flow for using AP4R is:
The focus for 0.3.x was Daemonization, URL-rewrite ﬁlter, 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 conﬁgurability, Automatic recovery, Blocking queues, and more.
- A client(e.g. a web browser) makes a request to a web server (Apache, Lighttpd, etc...).
- A rails application is synchronously executed on mongrel via mod_proxy or something.
- Rails app sends a message via AP4R APIs and can then immediatley respond to the client.
- AP4R queues the message and requests it to the web server asynchronously.
- The asynchronous business logic, implemented as usual rails action, is executed.
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
Delivering Performance Under Schedule and Resource Pressure: Lessons Learned at Google and Microsoft
Ivan Filho Mar 06, 2014