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. Bradley 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 > [email protected] > http://rubyforge.org/mailman/listinfo/mongrel-users _______________________________________________ Mongrel-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/mongrel-users
