Re: [ANN] unicorn 0.990.0 - inching towards 1.0

[Eric Wong <normalperson@yhbt.net>]

Alexander Simonov <alex@simonov.me> wrote:
> On Jun 9, 2010, at 9:22 PM, Eric Wong wrote:
> > Alexander Simonov <alex@simonov.me> wrote:
> >> 
> >> Hello!
> >> 
> >> One question: it's a normal state if i start rails app without preload
> >> and after Gem.refresh all works go down by exception from Ge.refresh
> >> and master process all time trying reup they.  And it's go to
> >> recursion. I know it's issue of people who start app, but in any case
> >> it's must be exception for stop of master process. Is i check code
> >> when starts workers and if we have preload_app false method run
> >> build_app!.  If we have preload_app true - then we check it before
> >> start worker. 
> > 
> > Hi Alexander,
> > 
> > I hope I'm understanding you correctly, so you want the master process
> > to die if you've misdeployed or misconfigured your app?
> 
> yes, something like this.
> 
> > 
> > This is one of those sharp edges of Unicorn that might be pointless
> > to protect against with preload_app=false...
> > 
> > The general rule is that you shouldn't be mucking around with Gem (or
> > any other library) installations on a production server unless you're
> > deploying.  And whenever you're deploying, you would always be checking
> > to see you've deployed correctly anyways, so you can detect any screwups
> > in the installation/deployment.
> > 
> > Let me know if that makes sense.
> 
> Ok. But the main thing is the master process goes to recursion restart
> of workers if they return exit or exception.May be add the counter?
> For example, 10 times we trying to respawn working process and after
> stop master.  I think it makes sense. 

It'd have to be a time-aware counter, because sometimes slightly broken
_will_ exit/die 10 times over the period of an hour.  But the site can
still be making enough money with 99.8% successful service and not
care about spending time/resources fixing the last 0.2% :)

But even with a proper time-aware counter, the app is still broken at
deploy time.  So I don't believe there is much point in adding more code
just to exit the process when the proper solution is for the user to
_fix_ the app.

And again (I seem to remember saying this months ago), any time you're
deploying, you should be paying extra attention to the app anyways.
That means testing with actual HTTP requests, not just seeing of the
process is up.  Just having a running process serving error pages is
equally worthless as not running the server at all.

-- 
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying