I'm a little concerned that merb has been emphasizing the "merb clusters" approach at the expense of the tried & trued "rails cluster" approach. I'm referring to:
1) Using a baked in spawner process to monitor merb processes instead of an external monitoring process like monit/god. As much as I like the idea merb monitoring itself, i've found ruby to be a poor monitoring tool. IMHO, the god project's biggest weakness is MRI. The language features and design tradeoffs make writing reliable monitoring tools a difficult task. As much as monit sucks, i trust it a whole heck of a lot more than merb's monitoring code, if only becuase it is not held down by the ruby runtime. C++ wasn't a silver bullet; neither is ruby. 2) The "spawn then wait to bind" approach to restarting a live app. I've had a few problems with it, my biggest have been merb failing to kill itself (with merb -K), which causes two simultaneous clusters, one with the pids consumed, and the other waiting to bind on the pids. This is hard to catch in production and has caused alot of headaches for me. IMHO, using haproxy/nginx or a combination of tools further down the stack is a much more elegent solution to restarting live apps. 2) Pushing REE/JRuby/whatever Ruby runtime instead of MRI to overcome current drawbacks with this approach on MRI. MRI is still Ruby, and merb's deployment strategy (at least the code in merb-core) should not adopt features that benifit one of these other runtimes at the expense of MRI, like requiring an extra process for the spawner. This opens the door for the "X sucks on MRI, use REE/JRuby/Rubinius/whatever instead" mentality that eventually leads to the assumption that merb apps are deployed on something other than MRI. I've switched back to using damonized merbs with monit using plain old "kill" to terminate/restart. Haproxy allows me to do fast deploys that can reaload init/production.rb. I'm not saying that "merb clustering" is a dead end, it might work great one day, but right now it is not a good solution for MRI, which is still Ruby. -Ben On Tue, Dec 2, 2008 at 10:40 AM, Yehuda Katz <[EMAIL PROTECTED]> wrote: > Are you bringing up the processes in development mode or production mode? > Merb will only wait in clustered mode, not in single-process daemonized mode > (clustered mode is merb -cN). > We're going to be making some improvements to the server in Merb 1.0.4 and > 1.0.5 to stabilize some deployment issues. It probably makes sense to have > single-process mode wait as well. > > -- Yehuda > > On Tue, Dec 2, 2008 at 8:23 AM, Steve Tooke <[EMAIL PROTECTED]> wrote: > >> >> Hi Yehuda, >> >> I think I'm missing something. If I try to start a new cluster when an >> old cluster is running I always get an error: >> >> FATAL: Merb is already running on port 8701. >> >> How can I bring up the new processes so that they will wait until the >> port becomes available? >> >> Steve >> >> On Thu, Nov 20, 2008 at 9:03 PM, Yehuda Katz <[EMAIL PROTECTED]> wrote: >> > Additionally, when you start up a merb that cannot bind to a port, it >> does >> > *not* immediately crash. Instead, it waits for the ports to become >> > available, and binds as soon as they do. This allows you to start up a >> new >> > merb, wait for it to come up, then gracefully kill the old process. As >> ports >> > die in the old deployment, they will immediately come online in the new >> > cluster. >> > However, this cannot work if the old and new deployment are in the same >> > directory, because as soon as you bring up the new cluster, it >> overwrites >> > the old pid files. For restarting in this scenario (at the moment), you >> need >> > to get the main pid first, store it off, then bring up the new process, >> and >> > send an INT to the stored pid. This is easy enough with a Ruby script or >> > bash script, but we will be adding explicit support for this via merb >> > --restart in the framework itself at some point in the future. >> >> >> > > > -- > Yehuda Katz > Developer | Engine Yard > (ph) 718.877.1325 > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "merb" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/merb?hl=en -~----------~----~----~----~------~----~------~--~---
