So the idea is this: When you start merb (with merb -cX) Merb starts up a master process and X children. It drops a merb.main.pid in your log directory, and X merb.PORT.pid files as well.
INTing a child process will cause it to be instantly respawned. This is what you should do if you want to restart a process that has grown too large (memory-wise). You can also achieve the same thing with merb -K <port>. The difference between -K and -k is that -K gracefully kills the process, allowing it to complete any requests or anything in the worker queue. merb -k is effectively a kill -9. If you want to kill the entire cluster, use merb -K all. This will gracefully kill the master process. merb -k all doesn't work at present, and there are some tricky ordering issues to deal with. 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. Hope that helped clear things up. -- Yehuda On Wed, Nov 19, 2008 at 2:28 PM, Yehuda Katz <[EMAIL PROTECTED]> wrote: > I'm going to reply in some detail after my talk today (at least to explain > what the intended arch is). > -- Yehuda > > > On Wed, Nov 19, 2008 at 2:12 PM, Michael D'Auria <[EMAIL PROTECTED] > > wrote: > >> I was actually hoping that the name option would be taken into account, >> for instance: >> >> merb -n myApp -p 4000 -c 2 >> >> Then it would be killed via: >> >> merb -K all -n myApp >> >> I am pretty sure that this would gracefully kill all currently running >> merbs. >> >> While we are here, what is the recomended way to start a merb app, with a >> cluster or will 1 master/worker pair handle a fair amount of traffic? >> >> Thanks, >> >> Michael >> >> On Wed, Nov 19, 2008 at 4:32 PM, Dermot Brennan <[EMAIL PROTECTED] >> > wrote: >> >>> >>> >>> OK but say you are running `merb -d -c 5 -p 4000` and then you run the >>> same thing again before sending INT to the first process, you will >>> just get a fatal message saying that merb is already running on that >>> port... >>> >>> On Nov 19, 6:17 pm, "Yehuda Katz" <[EMAIL PROTECTED]> wrote: >>> > Ha :) >>> > Sorry about that. >>> > >>> > At the moment, what you need to do is grab the PID from merb.main.pid, >>> start >>> > up a new process using whatever command you normally use to start up >>> the >>> > process, and then send an INT to the original PID. The other options >>> atm, >>> > using merb -K, require that you wait until the processes die before you >>> can >>> > start up the new process. This option allows you to have the new >>> processes >>> > primed and waiting for the old workers to die off. >>> > >>> > -- Yehuda >>> > >>> > On Wed, Nov 19, 2008 at 9:58 AM, Michael D'Auria >>> > <[EMAIL PROTECTED]>wrote: >>> > >>> > >>> > >>> > > I actually asked a similar question with no response. I hope you are >>> > > luckier than I :) >>> > >>> > > On Wed, Nov 19, 2008 at 12:12 PM, Dermot Brennan < >>> [EMAIL PROTECTED] >>> > > > wrote: >>> > >>> > >> I have a merb 1.0 application that I am deploying using capistrano. >>> > >> What is the best way of reloading the code after redeployment? >>> > >>> > >> merb -K all isn't working reliably for me and merb --fast-deploy >>> > >> doesn't reload the init.rb and gems. >>> > >>> > >> kill -HUP `cat log/merb.main.pid` >>> > >> restarts the work processes but I don't think it reloads the code. >>> > >>> > >> At the moment I have resorted to just killing all merb process and >>> > >> restarting the merb master process but that's not a graceful >>> solution. >>> > >> Is there a better way? >>> > >>> > >> -Dermot >>> > >>> > -- >>> > Yehuda Katz >>> > Developer | Engine Yard >>> > (ph) 718.877.1325 >>> >> >> >> >> >> > > > -- > Yehuda Katz > Developer | Engine Yard > (ph) 718.877.1325 > -- 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 -~----------~----~----~----~------~----~------~--~---
