mongrel_rails stop accepts a --wait argument. If I add that to mongrel_cluster, will it solve these issues?
Bradley 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. > > -carl > > On 4/12/07, Matt Zukowski <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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 >> [EMAIL PROTECTED] >> http://rubyforge.org/mailman/listinfo/mongrel-users >> > > _______________________________________________ Mongrel-users mailing list [EMAIL PROTECTED] http://rubyforge.org/mailman/listinfo/mongrel-users
