[Mongrel] [ANN] Another mongrel_cluster prerelease 220.127.116.11
Wayne E. Seguin
wayneeseguin at gmail.com
Thu Apr 12 11:10:16 EDT 2007
That makes total sense, thanks for that.
I agree that the best option seems to be to add a --wait option.
On Apr 12, 2007, at 11:04 , Rob Kaufman wrote:
> Hi Wayne,
> Though that is a good idea in general, it doesn't get the job done
> in this case. The problem is that stop returns successfully as soon
> as it sends the signal to the mongrel processes. It goes out, says
> "hey please stop what your doing" and then returns, telling you "I
> told them", not "they have stopped". It seems to me like what we need
> is to have a --wait option. The idea would be that mongrel_rails stop
> --wait would not return until it had confirmed that all the processes
> had truly stopped what they where doing. It would be nice if wait
> took an optional timeout argument.
> I see two benefits to this solution. One it solves the problem
> we're discussing here. Your cluster reset could be composed of stop
> --wait and start commands. Second it will allow your system shutdown
> or deployments to wait for every doggy to finish up and gracefully
> return your maintenance page instead of just timing out.
> Rob Kaufman
> On 4/12/07, Wayne E. Seguin <wayneeseguin at gmail.com> wrote:
>> This may be a bit simple, but couldn't you concatenate the commands
>> in a system call using either ';' (or &&), doesn't this (or both?) of
>> them require that the previous command finishes before executing the
>> current one?
>> What I'm thinking is that you can do something like:
>> `mongrel_rails stop... ; mongrel_rails start`
>> To accomplish the correct wait for the graceful stop?
>> I hope I'm not way off here as I just joined the discussion.
>> On Apr 11, 2007, at 19:56 , Michael A. Schoen wrote:
>>> Bradley Taylor wrote:
>>>> Reviewing the code (Zed correct me if I'm wrong), stop and restart
>>>> call the same stop method. The graceful handling of an in-progress
>>>> request is the same.
>>> Yes, and that handling works for me. The problem is that a
>>> fails when the stop takes a bit, whereas a stop-with-restart will
>>> be just fine.
>>> What happens now when I do a cluster restart is that some of my
>>> end up just dead, as they actually stop (gracefully) after the
>>> start has
>>> already been called for. I could resolve this using a forced
>>> stop, but
>>> I'm looking for a more, not less, graceful process.
>>>> 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
>>>> 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
>>>> mongrel with its own configuration file would behave as expected.
>>> Ah, so I understand why you made the change to have a cluster
>>> restart do
>>> a stop;start. We don't change the cluster configuration, so we
>>> hit by that problem.
>>> But would it be possible to get an alternative command added that
>>> do an actual restart? If not, no worries, I'll hack it in on my end.
>>> Mongrel-users mailing list
>>> Mongrel-users at rubyforge.org
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
More information about the Mongrel-users