[Mongrel] [ANN] Another mongrel_cluster prerelease

Bradley Taylor bradley at railsmachine.com
Wed Apr 11 17:12:59 EDT 2007

Sorry too many things going on... I was looking at the soft option.

Reviewing the code (Zed correct me if I'm wrong), stop and restart both 
call the same stop method. The graceful handling of an in-progress 
request is the same.

Restart also has some funky semantics when used in a cluster where it 
reuses the the command line arguments. This means that you can't modify 
the cluster configuration and apply the changes with a restart. The 
standard behavior of a linux (freebsd, etc) service is that 
configuration changes are reread on restart (apache, mysql,etc). So for 
the purposes of mongrel_cluster, restart == stop;start. Running a single 
mongrel with its own configuration file would behave as expected.


Michael A. Schoen wrote:
> Bradley Taylor wrote:
>> Unfortunately, this is not reliable for major changes and doing 
>> stop/start is the only way to guarantee that code changes will be applied.
>>  From the mongrel code (rails.rb, line 164):
>> # Reloads Rails.  This isn't too reliable really, but it
>> # should work for most minimal reload purposes.  The only reliable
>> # way to reload properly is to stop and then start the process.
> Ah, but that's not what I'm suggesting -- a "reload" is distinct from a 
> "restart". The "reload" option for Rails under Mongrel (from a HUP 
> signal) just calls the Rails reload! method, and I understand how that 
> can/will fail.
> A "restart" (from a USR2 signal) just a plain old regular stop, with the 
>   restart flag set such that once the Mongrel is stopped, it restarts.
> This should nicely handle the situation in which a Mongrel might take a 
> few seconds to shutdown (thereby missing it's start oppty).
> Make sense?
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

More information about the Mongrel-users mailing list