unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help
 help / color / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
						download: 
* [ANN] unicorn 0.990.0 - inching towards 1.0
@ 2010-06-08  9:51 Eric Wong
  2010-06-09  8:39 ` Alexander Simonov
  2010-06-11 20:37 ` Eric Wong
  0 siblings, 2 replies; 9+ results
From: Eric Wong @ 2010-06-08  9:51 UTC (permalink / raw)
  To: mongrel-unicorn

Unicorn is an HTTP server for Rack applications designed to only serve
fast clients on low-latency, high-bandwidth connections and take
advantage of features in Unix/Unix-like kernels.  Slow clients should
only be served by placing a reverse proxy capable of fully buffering
both the the request and response in between Unicorn and slow clients.

* http://unicorn.bogomips.org/
* mongrel-unicorn@rubyforge.org
* git://git.bogomips.org/unicorn.git

Changes:

Thanks to Augusto Becciu for finding a bug in the HTTP parser
that caused a TypeError (and 500) when a rare client set the
"Version:" header which conflicts with the HTTP_VERSION header
we parse in the first line of the request[1].

Horizontal tabs are now allowed as leading whitespace in header
values as according to RFC 2616 as pointed out by
Iñaki Baz Castillo[2].

Taking a hint from Rack 1.1, the "logger" configuration
parameter no longer requires a "close" method.  This means some
more Logger replacements may be used.

There's a new, optional, Unicorn (and maybe Passenger)-only
middleware, Unicorn::OobGC[2] that runs GC outside of the normal
request/response cycle to help out memory-hungry applications.
Thanks to Luke Melia for being brave enough to test and report
back on my big_app_gc.rb monkey patch[3] which lead up to this.

Rails 3 (beta) support:

  Using "unicorn" is still recommended as Rails 3 comes with
  a config.ru, but "unicorn_rails" is cleaned up a bit and
  *should* work as well as "unicorn" out-of-the-box.  Feedback
  is much appreciated.

Rubinius updates:

  USR2 binary upgrades are broken due to
  {TCPServer,UNIXServer}.for_fd[5][6] being broken
  (differently).

  Repeatedly hitting the server with signals in a tight
  loop is unusual and not recommended[7].

  There are some workarounds and general code cleanups for other
  issues[8], as well but things should generally work unless you
  need USR2 upgrades.  Feedback and reports would be greatly
  appreciated as usual.

MRI support:

  All tests (except old Rails) run and pass under 1.9.2-preview3.
  1.8.7 and 1.9.1 work well as usual and will continue to be
  supported indefinitely.

Lets hope this is the last release before 1.0.  Please report
any issues on the mailing list[9] or email us privately[a].
Don't send HTML mail.

[1] - http://mid.gmane.org/AANLkTimuGgcwNAMcVZdViFWdF-UcW_RGyZAue7phUXps@mail.gmail.com
[2] - http://mid.gmane.org/i2xcc1f582e1005070651u294bd83oc73d1e0adf72373a@mail.gmail.com
[3] - http://unicorn.bogomips.org/Unicorn/OobGC.html
[4] - http://unicorn.bogomips.org/examples/big_app_gc.rb
[5] - http://github.com/evanphx/rubinius/issues/354
[6] - http://github.com/evanphx/rubinius/issues/355
[7] - http://github.com/evanphx/rubinius/issues/356
[8] - http://github.com/evanphx/rubinius/issues/347
[9] - mailto:mongrel-unicorn@rubyforge.org
[a] - mailto:unicorn@bogomips.org

-- 
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


^ permalink raw reply	[relevance 4%]

* Re: [ANN] unicorn 0.990.0 - inching towards 1.0
  2010-06-08  9:51 [ANN] unicorn 0.990.0 - inching towards 1.0 Eric Wong
@ 2010-06-09  8:39 ` Alexander Simonov
  2010-06-09 18:22   ` Eric Wong
  2010-06-11 20:37 ` Eric Wong
  1 sibling, 1 reply; 9+ results
From: Alexander Simonov @ 2010-06-09  8:39 UTC (permalink / raw)
  To: unicorn list


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. 
 
_______________________________________________
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


^ permalink raw reply	[relevance 7%]

* Re: [ANN] unicorn 0.990.0 - inching towards 1.0
  2010-06-09  8:39 ` Alexander Simonov
@ 2010-06-09 18:22   ` Eric Wong
  2010-06-10  5:26     ` Alexander Simonov
  0 siblings, 1 reply; 9+ results
From: Eric Wong @ 2010-06-09 18:22 UTC (permalink / raw)
  To: unicorn list

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?

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.

-- 
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


^ permalink raw reply	[relevance 7%]

* Re: [ANN] unicorn 0.990.0 - inching towards 1.0
  2010-06-09 18:22   ` Eric Wong
@ 2010-06-10  5:26     ` Alexander Simonov
  2010-06-10  7:38       ` Eric Wong
  0 siblings, 1 reply; 9+ results
From: Alexander Simonov @ 2010-06-10  5:26 UTC (permalink / raw)
  To: unicorn list


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. 

_______________________________________________
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


^ permalink raw reply	[relevance 7%]

* Re: [ANN] unicorn 0.990.0 - inching towards 1.0
  2010-06-10  5:26     ` Alexander Simonov
@ 2010-06-10  7:38       ` Eric Wong
  2010-06-10  8:46         ` Alexander Simonov
  0 siblings, 1 reply; 9+ results
From: Eric Wong @ 2010-06-10  7:38 UTC (permalink / raw)
  To: unicorn list

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


^ permalink raw reply	[relevance 6%]

* Re: [ANN] unicorn 0.990.0 - inching towards 1.0
  2010-06-10  7:38       ` Eric Wong
@ 2010-06-10  8:46         ` Alexander Simonov
  2010-06-11  1:27           ` Eric Wong
  0 siblings, 1 reply; 9+ results
From: Alexander Simonov @ 2010-06-10  8:46 UTC (permalink / raw)
  To: unicorn list


On Jun 10, 2010, at 10:38 AM, Eric Wong wrote:

> 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.

Hm.. It's makes sense.
But much better if it will be writing in the documentation for the future.

Thank you!

_______________________________________________
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


^ permalink raw reply	[relevance 7%]

* Re: [ANN] unicorn 0.990.0 - inching towards 1.0
  2010-06-10  8:46         ` Alexander Simonov
@ 2010-06-11  1:27           ` Eric Wong
  2010-06-11 18:00             ` Alexander Simonov
  0 siblings, 1 reply; 9+ results
From: Eric Wong @ 2010-06-11  1:27 UTC (permalink / raw)
  To: unicorn list

Alexander Simonov <alex@simonov.me> wrote:
> On Jun 10, 2010, at 10:38 AM, Eric Wong wrote:
> > 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.
> 
> Hm.. It's makes sense.
> But much better if it will be writing in the documentation for the future.

Here's what I've pushed out, let me know if everything makes
sense.  I think I'll release 0.991.0 in a little bit.

>From f9baab18705218dae4c37c2c92d1ceea151bba8e Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Thu, 10 Jun 2010 17:57:08 -0700
Subject: [PATCH] docs: hopefully clarify preload_app=false behavior

While we're at it, inform people of why they might use
a symlink
---
 SIGNALS                     |    7 ++++++-
 lib/unicorn/configurator.rb |   21 ++++++++++++++++++---
 2 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/SIGNALS b/SIGNALS
index be96892..8851775 100644
--- a/SIGNALS
+++ b/SIGNALS
@@ -14,7 +14,12 @@ Unicorn and nginx.
   will also pick up any application code changes when restarted.  If
   "preload_app" is true, then application code changes will have no
   effect; USR2 + QUIT (see below) must be used to load newer code in
-  this case.
+  this case.  When reloading the application, +Gem.refresh+ will
+  be called so updated code for your application can pick up newly
+  installed RubyGems.  It is not recommended that you uninstall
+  libraries your application depends on while Unicorn is running,
+  as respawned workers may enter a spawn loop when they fail to
+  load an uninstalled dependency.
 
 * INT/TERM - quick shutdown, kills all workers immediately
 
diff --git a/lib/unicorn/configurator.rb b/lib/unicorn/configurator.rb
index 71c7a8a..533e0ed 100644
--- a/lib/unicorn/configurator.rb
+++ b/lib/unicorn/configurator.rb
@@ -311,7 +311,22 @@ module Unicorn
     #
     # In addition to reloading the unicorn-specific config settings,
     # SIGHUP will reload application code in the working
-    # directory/symlink when workers are gracefully restarted.
+    # directory/symlink when workers are gracefully restarted when
+    # preload_app=false (the default).  As reloading the application
+    # sometimes requires RubyGems updates, +Gem.refresh+ is always
+    # called before the application is loaded (for RubyGems users).
+    #
+    # During deployments, care should _always_ be taken to ensure your
+    # applications are properly deployed and running.  Using
+    # preload_app=false (the default) means you _must_ check if
+    # your application is responding properly after a deployment.
+    # Improperly deployed applications can go into a spawn loop
+    # if the application fails to load.  While your children are
+    # in a spawn loop, it is is possible to fix an application
+    # by properly deploying all required code and dependencies.
+    # Using preload_app=true means any application load error will
+    # cause the master process to exit with an error.
+
     def preload_app(bool)
       case bool
       when TrueClass, FalseClass
@@ -344,9 +359,9 @@ module Unicorn
       set_path(:stdout_path, path)
     end
 
-    # sets the working directory for Unicorn.  This ensures USR2 will
+    # sets the working directory for Unicorn.  This ensures SIGUSR2 will
     # start a new instance of Unicorn in this directory.  This may be
-    # a symlink.
+    # a symlink, a common scenario for Capistrano users.
     def working_directory(path)
       # just let chdir raise errors
       path = File.expand_path(path)
-- 
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


^ permalink raw reply	[relevance 5%]

* Re: [ANN] unicorn 0.990.0 - inching towards 1.0
  2010-06-11  1:27           ` Eric Wong
@ 2010-06-11 18:00             ` Alexander Simonov
  0 siblings, 0 replies; 9+ results
From: Alexander Simonov @ 2010-06-11 18:00 UTC (permalink / raw)
  To: unicorn list



On Jun 11, 2010, at 4:27 AM, Eric Wong wrote:

> Alexander Simonov <alex@simonov.me> wrote:
>> On Jun 10, 2010, at 10:38 AM, Eric Wong wrote:
>>> 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.
>> 
>> Hm.. It's makes sense.
>> But much better if it will be writing in the documentation for the future.
> 
> Here's what I've pushed out, let me know if everything makes
> sense.  I think I'll release 0.991.0 in a little bit.

Ok! Thank you!
Good. After release I will update golden_brindle too :)


> 
>> From f9baab18705218dae4c37c2c92d1ceea151bba8e Mon Sep 17 00:00:00 2001
> From: Eric Wong <normalperson@yhbt.net>
> Date: Thu, 10 Jun 2010 17:57:08 -0700
> Subject: [PATCH] docs: hopefully clarify preload_app=false behavior
> 
> While we're at it, inform people of why they might use
> a symlink

_______________________________________________
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


^ permalink raw reply	[relevance 7%]

* Re: [ANN] unicorn 0.990.0 - inching towards 1.0
  2010-06-08  9:51 [ANN] unicorn 0.990.0 - inching towards 1.0 Eric Wong
  2010-06-09  8:39 ` Alexander Simonov
@ 2010-06-11 20:37 ` Eric Wong
  1 sibling, 0 replies; 9+ results
From: Eric Wong @ 2010-06-11 20:37 UTC (permalink / raw)
  To: mongrel-unicorn

Eric Wong <normalperson@yhbt.net> wrote:
> Rubinius updates:
>   but things should generally work unless you
>   need USR2 upgrades.  Feedback and reports would be greatly
>   appreciated as usual.

Log rotation for $stderr and $stdout (but not other
paths) are broken under Rubinius, too.  I only discovered this
while running the Rainbows! integration tests.

ref: http://github.com/evanphx/rubinius/issues/360

-- 
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


^ permalink raw reply	[relevance 7%]

Results 1-9 of 9 | reverse results
2010-06-08  9:51 [ANN] unicorn 0.990.0 - inching towards 1.0 Eric Wong
2010-06-09  8:39 ` Alexander Simonov
2010-06-09 18:22   ` Eric Wong
2010-06-10  5:26     ` Alexander Simonov
2010-06-10  7:38       ` Eric Wong
2010-06-10  8:46         ` Alexander Simonov
2010-06-11  1:27           ` Eric Wong
2010-06-11 18:00             ` Alexander Simonov
2010-06-11 20:37 ` Eric Wong


unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help

Archives are clonable:
	git clone --mirror https://bogomips.org/unicorn-public
	git clone --mirror http://ou63pmih66umazou.onion/unicorn-public

Example config snippet for mirrors

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.lang.ruby.unicorn
	nntp://ou63pmih66umazou.onion/inbox.comp.lang.ruby.unicorn

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git