[Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
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.
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
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
More information about the Mongrel-users
mailing list