From: Robert Klemme <shortcutter@...>
Date: 2010-12-07T00:46:06+09:00
Subject: Re: Ruby dispatcher and work processes

On Mon, Dec 6, 2010 at 4:08 PM, Martin C. <mydoghasworms@gmail.com> wrote:
> I would like to implement an (open source) application platform
> analogous to SAP's ABAP platform in Ruby. (See below for link to SAP
> architecture diagrams).

Maybe the announced fairy framework is for you.

> In part, this requires having different Ruby processes talk to each
> other, specifically having one dispatcher process dishing out work to
> standalone work processes.

You could have a Queue instance and have several worker processes read
from it via DRb.  That would be about the simplest scenario I can
think of.

> I am at a loss though as to how to go about this. In part, one stumbling
> block I see is that if each work process is a Ruby process, I might load
> ruby code (files/programs) into memory in a work process, but I couldn't
> release it again. (Obviously I don't want to incur the expense of
> starting up Ruby for each incoming request).

You could terminate a worker process after it has processed a number
of requests or has run for a particular time thus balancing process
creation overhead and memory usage.

> Any ideas on what existing frameworks I could look at? I was
> wondering about using MagLev, especially to take advantage of storing
> data in shared memory between processes in an easy way. (i.e. each work
> process would be a MagLev instance).

Whether I would add the complexity of shared memory I would make
dependent on the amount of data that needs to be shared.  If requests
and responses are small I would certainly not use shmem.  Also, if the
data is read and stored elsewhere (e.g. RDBMS) I'd probably not bother
to use shmem.

Kind regards

robert


PS: Get well soon to your dog!

PPS: I see Pink does not need to wait any more.

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/