From: "Martin C." Date: 2010-12-07T00:59:55+09:00 Subject: Re: Ruby dispatcher and work processes Robert Klemme wrote in post #966549: > On Mon, Dec 6, 2010 at 4:08 PM, Martin C. > 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. > Fairy framework? >> 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. > SAP's method of dispatching works on a "push" rather than a "pull" as far as I can tell. >> 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. > Sounds complex, but I guess is worth looking into. Is there a way of reloading a class instead? I.e. If all "programs" or "applications" executed on the platform were implemented as a particular class, perhaps reloading that class with new content could work? >> 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. > The advantage is that if one process handles your current request and a different one your next, they need only attach to the shared memory without unloading and reloading or the overhead of persisting to a database between requests (or that is at least the thinking - SAP obviously have perfected this over literally decades). > Kind regards > > robert > Much appreciated, thanks. > > PS: Get well soon to your dog! > > PPS: I see Pink does not need to wait any more. -- Posted via http://www.ruby-forum.com/.