Iñáki Baz Castillo <ibc / aliax.net> wrote:
> Hi, I run Unicorn which is a Rack http server using N forked worker processes. 
> I need the following:
> 
> - When a worker processes a HTTP request it must notify some data to other 
> independent Ruby process XXX (different than Unicorn).
> 
> - This communication must be non-blocking, this is, the Unicorn worker process 
> sends the notification and doesn't wait for response from the process XXX, so 
> the Unicorn worker can, at the moment, generate the HTTP response and send 
> back to the client, getting free to handle new HTTP requests.

If stressed enough, everything has to block/reject or run your systems
out of memory/disk space :)

> - The ruby process XXX should use some kind of queue system to store 
> notifications and handle them. In fact, it should take them periodically and 
> send via TCP (but not HTTP) to other server.
> 
> 
> Which is the best approach to design such communication? perhaps using 
> something as EventMachine for the XXX process and Unix/TCP socket 
> communication between Unicorn processes and XXX process? any other alternative 
> or suggestion?

If you only talk between processes on one machine (since you're trying
FIFOs), you can also check out the "posix_mq" gem/library I started
recently:

	http://bogomips.org/ruby_posix_mq/

It's less portable than FIFOs but if you're running a modern GNU/Linux or
FreeBSD, it should work.  The default queue sizes on Linux are small:
8192 bytes per message, and 10 messages in the queue.  You'll need
root to increase them.

But then FIFOs are hard-coded to 65536 bytes total under Linux and a
4096 byte PIPE_BUF (POSIX only requires a 512 byte PIPE_BUF).

-- 
Eric Wong