Date | Commit message (Collapse) |
|
ivar references using @ are slightly faster than calling
attribute methods.
|
|
Oops, it messes logging up badly.
|
|
chunk_ready! was my original name for it, but I'm indecisive
when it comes to naming things.
|
|
This allows one to enter the dechunker without parsing
HTTP headers beforehand. Since we skipped header parsing,
trailer parsing is not supported since we don't know
what trailers might be (to our knowledge, nobody uses trailers
anyways)
|
|
copy-on-write behavior doesn't help you if your common
use case triggers copies.
|
|
Makes things easier-to-understand since it's based on memcpy()
|
|
These TCP settings are a closer match to the behavior of
Unix domain sockets and what users expect for fast streaming
responses even if nginx can't provide them just now...
|
|
kgio 2.4.1 portability should be better than 2.3, so
less user confusion and push them towards 2.4
|
|
This reduces the size of `caller` by 5 frames,
which should make backtraces easier-to-read, raising
exceptions less expensive, and reduce GC runtime.
|
|
Stack depth affects Ruby GC performance, so lowering it
makes sense
|
|
* miscellaneous documentation improvements
* return 414 (instead of 400) for Request-URI Too Long
* strip leading and trailing linear whitespace in header values
User-visible improvements meant for Rainbows! users:
* add :ipv6only "listen" option (same as nginx)
|
|
Enabling this flag for an IPv6 TCP listener allows users to
specify IPv6-only listeners regardless of the OS default.
This should be interest to Rainbows! users.
|
|
Original patch by Hongli Lai <hongli@phusion.nl>:
> >From bfefc2cf0efb0913a42862886363b3140dcdbb2a Mon Sep 17 00:00:00 2001
> From: Hongli Lai (Phusion) <hongli@phusion.nl>
> Date: Mon, 6 Jun 2011 13:39:00 +0200
> Subject: [PATCH] Ensure that 'make gem' builds the documentation too.
>
> If autogenerated documentation files, like man pages, don't exist then
> 'make gem' will fail, complaining that some files are not found. By
> depending the 'gem' target on the 'doc' target we ensure that 'make gem'
> always works.
>
> Signed-off-by: Hongli Lai (Phusion) <hongli@phusion.nl>
ref: http://mid.gmane.org/4DED0EE2.7040400@phusion.nl
|
|
Oops.
|
|
IPv4-mapped-IPv6 addresses are fugly.
|
|
pandoc 1.8 no longer has this.
|
|
Signed-off-by: Hongli Lai (Phusion) <hongli@phusion.nl>
|
|
Rails 3.0.0 can't use Rake 0.9.0 it seems.
|
|
It's required for RubyGems 1.8.x
|
|
Ruby 1.9.3dev (trunk) requires it if the string size
is unchanged.
|
|
RFC 2616, section 4.2:
> The field-content does not include any leading or trailing LWS:
> linear white space occurring before the first non-whitespace
> character of the field-value or after the last non-whitespace
> character of the field-value. Such leading or trailing LWS MAY be
> removed without changing the semantics of the field value. Any LWS
> that occurs between field-content MAY be replaced with a single SP
> before interpreting the field value or forwarding the message
> downstream.
|
|
Older announcements on our mailing list could be harder
to find.
|
|
Otherwise it could casefold and we don't want that.
|
|
No need to list things inside preformatted text
|
|
Rainbows! wants to be able to lower this eventually...
|
|
"wait" needs to be done in the outside shell because
the subshell could still be exiting when we grep.
|
|
|
|
Combines the following sequence:
http_parser.buf << socket.readpartial(0x4000)
http_parser.parse
Into:
http_parser.add_parse(socket.readpartial(0x4000))
It was too damn redundant otherwise...
|
|
There's an HTTP status code allocated for it in
<http://www.iana.org/assignments/http-status-codes>, so
return that instead of 400.
|
|
Bundler 1.0.x is much improved :)
|
|
The optional Unicorn::OobGC module is reimplemented to fix
breakage that appeared in v3.3.1. There are also minor
documentation updates, but no code changes as of 3.6.1 for
non-OobGC users.
There is also a v1.1.7 release to fix the same OobGC breakage
that appeared for 1.1.x users in the v1.1.6 release.
|
|
* commit 'v1.1.7':
unicorn 1.1.7 - major fixes to minor components
oob_gc: reimplement to fix breakage and add tests
exec_cgi: handle Status header in CGI response
unicorn 1.1.6 - one minor, esoteric bugfix
close client socket after closing response body
|
|
|
|
No changes to the core code, so this release only affects users
of the Unicorn::OobGC and Unicorn::ExecCGI modules.
Unicorn::OobGC was totally broken by the fix in the v1.1.6
release and is now reimplemented. Unicorn::ExecCGI (which
hardly anybody uses) now returns proper HTTP status codes.
|
|
This was broken since v3.3.1[1] and v1.1.6[2] since nginx relies on
a closed socket (and not Content-Length/Transfer-Encoding) to
detect a response completion. We have to close the client
socket before invoking GC to ensure the client sees the response
in a timely manner.
[1] - commit b72a86f66c722d56a6d77ed1d2779ace6ad103ed
[2] - commit b7a0074284d33352bb9e732c660b29162f34bf0e
(cherry picked from commit faeb3223636c39ea8df4017dc9a9d39ac649b26d)
Conflicts:
examples/big_app_gc.rb
lib/unicorn/oob_gc.rb
|
|
It seems people are still confused about it...
|
|
This was broken since v3.3.1[1] since nginx relies on a closed
socket (and not Content-Length/Transfer-Encoding) to detect
a response completion. We have to close the client socket
before invoking GC to ensure the client sees the response
in a timely manner.
[1] - commit b72a86f66c722d56a6d77ed1d2779ace6ad103ed
|
|
|
|
Oops, comments should match the latest code
|
|
OobGC is actually broken with nginx these days since
we needed to preserve the env for body.close...
|
|
These options will probably be more important as interest in
streaming responses in Rails 3.1 develops.
I consider the respective defaults for Unicorn (designed to run
behind nginx) and Rainbows! (designed to run standalone) to be
the best choices in their respective environments.
|
|
I've tested with nginx 1.0.0 and confirmed "proxy_buffering off;"
can cause Unicorn to block on a slow client reading a
large response. While there's a potential (client-visible)
performance improvement with Rails 3.1 streaming responses, it
can also hurt the server with slow clients.
Rainbows! with (ThreadSpawn or ThreadPool) is probably the best
way to do streaming responses efficiently from all angles (from
a server, client and programmer time perspective).
|
|
Our attempt in 3.6.0 to workaround a problem with the OpenSSL
PRNG actually made the problem worse. This release corrects the
workaround to properly reseed the OpenSSL PRNG after forking.
|
|
Using the return value of Kernel#srand actually made the
problem worse. Using the value of Kernel#rand is required
to actually get a random value to seed the OpenSSL PRNG.
Thanks to ghazel for the bug report!
|
|
Mainly small fixes, improvements, and workarounds for fork() issues
with pseudo-random number generators shipped with Ruby (Kernel#rand,
OpenSSL::Random (used by SecureRandom and also by Rails).
The PRNG issues are documented in depth here (and links to Ruby Redmine):
http://bogomips.org/unicorn.git/commit?id=1107ede7
http://bogomips.org/unicorn.git/commit?id=b3241621
If you're too lazy to upgrade, you can just do this in your after_fork
hooks:
after_fork do |server,worker|
tmp = srand
OpenSSL::Random.seed(tmp.to_s) if defined?(OpenSSL::Random)
end
There are also small log reopening (SIGUSR1) improvements:
* relative paths may also be reopened, there's a small chance this
will break with a handful of setups, but unlikely. This should
make configuration easier especially since the "working_directory"
configurator directive exists. Brought up by Matthew Kocher:
http://thread.gmane.org/gmane.comp.lang.ruby.unicorn.general/900
* workers will just die (and restart) if log reopening fails for
any reason (including user error). This is to workaround the issue
reported by Emmanuel Gomez:
http://thread.gmane.org/gmane.comp.lang.ruby.unicorn.general/906
|
|
Older Rainbows! redefines the ready_pipe= accessor method
to call internal after_fork hooks.
|
|
|
|
Don't clutter up our RDoc/website with things that users
of Unicorn don't need to see. This should make user-relevant
documentation easier to find, especially since Unicorn is
NOT intended to be an API.
|
|
OpenSSL seeds its PRNG with the process ID, so if a process ID
is recycled, there's a chance of indepedent workers getting
repeated PRNG sequences over a long time period iff the same
PID is used.
This only affects deployments that meet both of the following
conditions:
1) OpenSSL::Random.random_bytes is called before forking
2) worker (but not master) processes are die unexpectedly
The SecureRandom module in Ruby (and Rails) uses the OpenSSL
PRNG if available. SecureRandom is used by Rails and called
when the application is loaded, so most Rails apps with
frequently dying worker processes are affected.
Of course dying worker processes are bad and entirely the
fault of bad application/library code, not the fault of
Unicorn.
Thanks for Alexander Dymo for reporting this.
ref: http://redmine.ruby-lang.org/issues/4579
|
|
The current versions of Ruby 1.8 do not reseed the PRNG after
forking, so we'll work around that by calling Kernel#srand.
ref: http://redmine.ruby-lang.org/issues/show/4338
|