[Mongrel] Unix Domain Sockets + Fork for improved scalability
Zed A. Shaw
zedshaw at zedshaw.com
Tue May 6 01:59:17 EDT 2008
On Mon, May 05, 2008 at 11:37:56PM -0400, Brian Weaver wrote:
> Hello All,
> Ticket #30 (http://mongrel.rubyforge.org/ticket/30) has a set of
> changes to mongrel that I've written on behalf of
> my employer, Raritan Computer, Inc. Also, these changes are released
> under the existing Ruby license used for Mongrel.
Interesting Brian, glad you finally got the patch into the queue. :-)
> The attached patch does just that. It's definitely tailored for a Unix
> derivative platform and depends on the functionality of the UNIXSocket
> class to pass file descriptors between instances. It works in a
> master-slave type of server setup. The "master" is the initial
> instance of mongrel rails which goes through its normal initialization
> gyrations before forking mulitple "slave" instances to do the actual
> rails processing. The server listens on the defined TCP/IP address and
> port accepting request (from Apache in our case), determines which
> child if any is available, and then hands off the file descriptor for
So, I've just read through this patch, and correct me if I'm wrong, but
your patch removes the ability for Mongrel to run as a plain web server
right? There also seems to be no tests, so does it just use the
existing tests but within the confines of the new forking setup?
> The patch isn't without any warts. Due to the way that mongrel
> preforms initialization I found it difficult to follow the startup
> logic. Because of the convoluted
> contortions that occur during startup I was unable to
> make deeper changes due to time constraints which means that the
> following problem exists.
Can you describe what was confusing? The code's not too large so maybe
it just wasn't documented really clearly.
Also, had you tried just subclassing HttpServer and implementing the
alternative mechanism for both the master and slaves?
> * If you start the server as root and the configuration causes a
> setuid/setgid call to a non-root user then during shutdown mongrel may
> not be able to remove its pid file.
The pid file management has always been a mess because of ruby's very
poor process management, and just the variablility in POSIX anyway.
Eventually it'll just have to be a C api that does it right I think.
> I'm not aware of any other lurking problem, but I wouldn't be
> surprised if one or more exists.
> If you have any further question just send me a note or post to the
> list. I'll stay subscribed for a few weeks at least. Also, for the
> maintainers: I've added a copyright notice for Raritan Computer on
> those files that had extensive changes. I believe that is the correct
> way to handle major changes, let me know if I'm incorrect in my
Actually, and this is a big misnomer among open source folks, the
copyright isn't on a file, it's on the project. It's kind of like
saying if you edit a page in my book with a marker you get to put your
copyright on that page. Additionally there isn't enough change to that
file to warrant an entire copyright change as it's still primarily
written by myself and other project contributors.
What you can do is either officially donate it back to the project under
the original copyright with a small notice giving credit to yourself
and/or Raritan that you did the master/slave/unixsocket hack, or pull
this out into a separate, completely and wholely written by you/raritan
file that has none of my code and then release under your own license
however you like.
Talk it over with your corporate masters, but considering you have an
entire product based on other people's generously donated free work it
might be a really great nice thing to give back.
Makes people all warm and fuzzy and like your products in exchange.
Utu : http://savingtheinternetwithhate.com/
More information about the Mongrel-users