It appears the spawner in Rails 1.2 will do Mongrel clustering. I''m curious what this means for mongrel_cluster. They appear to overlap in features quite a bit. I don''t think the spawner uses a config, so that''s one difference. Will they be different enough? I only ask because mongrel_cluster could, theoretically, be made extinct if the spawner script has all the same features (why another gem if Rails duplicates the functionality). Just a curious question from a happy cluster user. :) -- Cheers, Kevin
Hi Kevin: On Jul 13, 2006, at 3:27 PM, Kevin Williams wrote:> I''m curious what this means for mongrel_cluster. They appear to > overlap in features quite a bit. I don''t think the spawner uses a > config, so that''s one difference. Will they be different enough?Great question. To be honest, spawner will be fine for many people. Here are the main differences: 1. With spawner you can specify starting port, environment, and number of mongrels. That''s it. If you need control over any of Mongrel''s other billion start options, then you''ll need mongrel_cluster. Of the options that don''t overlap with fcgi options, "address", "script", "chdir" and "user" are really handy. 2. mongrel_cluster provides an init.d script for start on boot and the ability to start/stop/restart all applications with mongrel_cluster_ctl. Roll your own with spawner. 3. mongrel_cluster provides Capistrano tasks for configuring your cluster and supporting #2 above. Roll your own with spawner (example in Cap manual). 4. mongrel_cluster views itself as one part of an entire application stack and thus tries to "blend in". It defaults to storing configuration files in ''/etc'' , using an init.d script, and providing control over the all the clusters on the server. It leans towards the "unix way" rather than the "rails way". 5. mongrel_cluster was born out of the need to easily configure and manage multiple rails applications on on a single server. These differences reflect the different needs of the authors. The extras that mongrel_cluster provides are not mandatory for using Mongrel in clustered way, but are useful in many deployments. For myself and most of my customers, mongrel_cluster won''t be obsolete, because it does work for us that we would have to do ourselves if we switched spawner. Thanks, Bradley Taylor ------ Rails Optimized Hosting ~ VPS and Dedicated Servers Simplified Deployment ~ Services and Software http://railsmachine.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060713/e6379d50/attachment.html
Excellent answer! Thanks. On 7/13/06, Bradley Taylor <bradley at railsmachine.com> wrote:> > Hi Kevin: > > > On Jul 13, 2006, at 3:27 PM, Kevin Williams wrote: > > > I''m curious what this means for mongrel_cluster. They appear to > overlap in features quite a bit. I don''t think the spawner uses a > config, so that''s one difference. Will they be different enough? > > Great question. To be honest, spawner will be fine for many people. > > Here are the main differences: > > 1. With spawner you can specify starting port, environment, and number of > mongrels. That''s it. If you need control over any of Mongrel''s other billion > start options, then you''ll need mongrel_cluster. Of the options that don''t > overlap with fcgi options, "address", "script", "chdir" and "user" are > really handy. > > 2. mongrel_cluster provides an init.d script for start on boot and the > ability to start/stop/restart all applications with mongrel_cluster_ctl. > Roll your own with spawner. > > 3. mongrel_cluster provides Capistrano tasks for configuring your cluster > and supporting #2 above. Roll your own with spawner (example in Cap manual). > > 4. mongrel_cluster views itself as one part of an entire application stack > and thus tries to "blend in". It defaults to storing configuration files in > ''/etc'' , using an init.d script, and providing control over the all the > clusters on the server. It leans towards the "unix way" rather than the > "rails way". > > 5. mongrel_cluster was born out of the need to easily configure and manage > multiple rails applications on on a single server. > > These differences reflect the different needs of the authors. The extras > that mongrel_cluster provides are not mandatory for using Mongrel in > clustered way, but are useful in many deployments. For myself and most of my > customers, mongrel_cluster won''t be obsolete, because it does work for us > that we would have to do ourselves if we switched spawner. > > Thanks, > Bradley Taylor > > ------ > Rails Optimized Hosting ~ VPS and Dedicated Servers > Simplified Deployment ~ Services and Software > http://railsmachine.com > > > > > > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > >-- Cheers, Kevin