[Mongrel] [ANN] Another mongrel_cluster prerelease 18.104.22.168
bradley at railsmachine.com
Thu Apr 12 16:07:34 EDT 2007
mongrel_rails stop accepts a --wait argument. If I add that to
mongrel_cluster, will it solve these issues?
Carl Lerche wrote:
> Yes, I have the same problem. On high traffic apps, mongrel cluster's
> restart will fail pretty consistently (for the reasons stated above).
> A --wait option seems like a reasonable solution.
> On 4/12/07, Matt Zukowski <mzukowski at urbacon.net> wrote:
>> For me at least the issue isn't so much constant and complete
>> availability... It's that the "restart" command in mongrel_cluster
>> basically doesn't work. After stopping, it tires to start without
>> waiting for the servers to shut down. Most of the time this fails, as
>> the old servers are still shutting down.
>> Instead I find myself doing a manual 'stop', then ps'ing repeatedly to
>> see if all the servers have shut down, and then starting manually.
>> Zed A. Shaw wrote:
>>> On Thu, 12 Apr 2007 10:15:13 -0700
>>> "Michael A. Schoen" <schoenm at earthlink.net> wrote:
>>>> Matt Zukowski wrote:
>>>>> Just a suggestion, but maybe the stop command should wait until all the
>>>>> servers are actually down before it exits. What Michael describes below
>>>>> is a fairly frustrating aspect of using mongrel_cluster. The restart
>>>>> process right now kind of sucks, and I suspect that making it behave
>>>>> more gracefully would make a lot of people happy.
>>>> And Mongrel itself does support a more graceful restart, mongrel_cluster
>>>> just doesn't use it at the moment. Even given the constraint that a true
>>>> restart won't re-read the cluster config, still seems worth being
>>>> available as an option.
>>> I think I'm going to say, no, you don't get this in mongrel_cluster.
>>> When we had it there were way too many problems because how Rails does
>>> this kind of soft restart isn't very clear. It's basically a bunch of
>>> black magic ruby that reloads all the stuff like in debug mode. That
>>> also means that it doesn't work with modules and systems that are
>>> outside of rails. For example, you can't hook into this restart
>>> process so that you can properly close connections to Jabber servers.
>>> This lead to people having weird problems like Mongrel not actually
>>> restarting and memory leaks. Of course, they don't blame Rails or the
>>> plugin they're using, they blame Mongrel. In order to keep the support
>>> problems to a minimum, we just stop the server and restart.
>>> What's wrong with that for people? Apparently you all need constant
>>> and completely available up-time for your web applications. Great.
>>> You can't get this from Mongrel, or from Rails, you need to look
>>> outside at your proxy server, network architecture, and other sources.
>>> However, you do have access to it. Every time mongrel starts up it
>>> tells you what posix signals cause what actions. If you want a
>>> graceful restart and you know it will work then you just hit your
>>> mongrels with that signal.
>> This e-mail message is privileged, confidential and subject to copyright. Any unauthorized use or disclosure is prohibited.
>> Le contenu du pr'esent courriel est privil'egi'e, confidentiel et soumis `a des droits d'auteur. Il est interdit de l'utiliser ou de le divulguer sans autorisation.
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
More information about the Mongrel-users