| Date | Commit message (Collapse) |
|---|
|
In my testing, only dropped clients over Unix domain sockets or
loopback TCP were detected with this option. Since many
nginx+unicorn combinations run on the same host, this is not a
problem.
Furthermore, tcp_nodelay:true appears to work over loopback,
so remove the requirement for tcp_nodelay:false.
|
|
This patch checks incoming connections and avoids calling the application
if the connection has been closed.
It works by sending the beginning of the HTTP response before calling
the application to see if the socket can successfully be written to.
By enabling this feature users can avoid wasting application rendering
time only to find the connection is closed when attempting to write, and
throwing out the result.
When a client disconnects while being queued or processed, Nginx will log
HTTP response 499 but the application will log a 200.
Enabling this feature will minimize the time window during which the problem
can arise.
The feature is disabled by default and can be enabled by adding
'check_client_connection true' to the unicorn config.
[ew: After testing this change, Tom Burns wrote:
So we just finished the US Black Friday / Cyber Monday weekend running
unicorn forked with the last version of the patch I had sent you. It
worked splendidly and helped us handle huge flash sales without
increased response time over the weekend.
Whereas in previous flash traffic scenarios we would see the number of
HTTP 499 responses grow past the number of real HTTP 200 responses,
over the weekend we saw no growth in 499s during flash sales.
Unexpectedly the patch also helped us ward off a DoS attack where the
attackers were disconnecting immediately after making a request.
ref: <CAK4qKG3rkfVYLyeqEqQyuNEh_nZ8yw0X_cwTxJfJ+TOU+y8F+w@mail.gmail.com>
]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
|
|
There's no practical difference between a timeout of 30 days and
68 years from an HTTP server standpoint.
POSIX limits us to 31 days, actually, but there could be
rounding error with floats used in Ruby time calculations and
there's no real difference between 30 and 31 days, either...
Thanks to Jeremy Evans for pointing out large values will throw
EINVAL (on select(2) under OpenBSD with Ruby 1.9.3 and
RangeError on older Rubies.
|
|
This will also be the foundation of SSL support in Rainbows!
and Zbatery. Some users may also want to use this in
Unicorn on LANs to meet certain security/auditing requirements.
Of course, Nightmare! (in whatever form) should also be able to
use it.
|
|
Nobody will miss one second if they specify an "infinite"
timeout of ~68 years. This prevents duplicating this logic
in Rainbows!
|
|
IO.select in Ruby can't wait longer than this. This
means Unicorn can't support applications that take
longer than 68 years to respond :(
|
|
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...
|
|
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.
|
|
It seems people are still confused about it...
|
|
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.
|
|
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.
|
|
Oops, changing a method definition for RDoc means code
needs to be updated, too :x
|
|
Mainly formatting and such, but some wording changes.
|
|
Configurator itself supports user at the top-level.
|
|
This is much like how nginx does it, except we always require a
port when explicitly binding to IPv6 using the "listen"
directive. This also adds support to listen with an
address-only, which can be useful to Rainbows! users.
|
|
It's actually harmless since Unicorn only supports "fast"
applications that do not trickle, and we don't do keepalive so
we'll always flush-on-close. This should reduce wakeups on the
nginx proxy server if nginx is over TCP. Mongrel 1.x had
TCP_CORK enabled by default, too.
|
|
This may not be supported in the future...
|
|
This is the most important part of Unicorn documentation
for end users.
|
|
More config bloat, sadly this is necessary for Rainbows! :<
|
|
This release enables tuning the client_buffer_body_size to raise
or lower the threshold for buffering request bodies to disk.
This only applies to users who have not disabled rewindable
input. There is also a TeeInput bugfix for uncommon usage
patterns and Configurator examples in the FAQ should be fixed
|
|
Since modern machines have more memory these days and
clients are sending more data, avoiding potentially slow
filesystem operations for larger uploads can be useful
for some applications.
|
|
This has been broken since 2.0.x
Internal cleanups sometimes have unintended consequences :<
|
|
This allows users to override the current Rack spec and disable
the rewindable input requirement. This can allow applications
to use less I/O to minimize the performance impact when
processing uploads.
|
|
If a configuration directive is set at startup and later
unset, it correctly restores the original default value
as if it had never been set in the first place.
This applies to the majority of the configuration values with
a few exceptions:
* This only applies to stderr_path and stdout_path when
daemonized (the usual case, they'll be redirected to
"/dev/null"). When NOT daemonized, we cannot easily redirect
back to the original stdout/stderr destinations.
* Unsetting working_directory does not restore the
original working directory where Unicorn was started.
As far as we can tell unsetting this after setting it is
rarely desirable and greatly increases the probability of
user error.
|
|
It's less ambiguous since this is a network server after all.
|
|
No point in using a Struct for (1.8) space-efficiency
if there's only one of them.
|
|
These nasty hacks were breaking Rubinius compatibility.
This can be further cleaned up, too.
|
|
No point in redeclaring the Unicorn module in here.
|
|
The defaults should be reasonable, but there may be
folks who want to experiment.
|
|
While we're at it, inform people of why they might use
a symlink
|
|
|
|
|
|
Since we added support for the "working_directory" parameter, it
often became unclear where/when certain paths would be bound.
There are some extremely nasty dependencies and ordering issues
when doing this. It's all pretty fragile, but works for now
and we even have a full integration test to keep it working.
I plan on cleaning this up 2.x.x to be less offensive to look
at (Rainbows! and Zbatery are a bit tied to this at the moment).
Thanks to Pierre Baillet for reporting this.
ref: http://mid.gmane.org/AANLkTimKb7JARr_69nfVrJLvMZH3Gvs1o_KwZFLKfuxy@mail.gmail.com
|
|
...than "test ?r" and "test ?w"
Not everybody comes from a Unix shell programming background,
even though they *should* ;)
|
|
Rack::Lint in Rack 1.1.0 does not require a "close" method for
env["rack.logger"], and we never explicitly close our logger,
either. This more easily allows the use of alternative
Logger-like implementations such as SyslogLogger.
|
|
While second nature to myself, stderr_path may be an
overlooked configuration parameter for some users. Also,
add a minimal sample configuration file that is shorter
and hopefully less intimidating to new users.
|
|
Allowing the "user" directive outside of after_fork reduces the
cognitive overhead for folks that do not need the complexity of
*_fork hooks. Using Worker#user remains supported as it offers
fine-grained control of user switching.
|
|
The temporary paths we create to mimic script/server-emulation
did not work when working_directory was used. Now we defer
path creation until after working_directory is bound.
|
|
No point in repeating ourselves and having to deal with nested
comments + indentation in RDoc. It's also easier for users
to just download the file than to copy-and-paste out of a
typical web browser.
|
|
Shells already expand '~' before the executables see it, and
relative paths inside symlinks can get set incorrectly to the
actual directory name, and not the (usually desired) symlink
name for things like Capistrano.
Since our paths are now unexpanded, we must now check the
"working_directory" directive and raise an error if the user
specifies the config file in a way that makes the config file
unreloadable.
|
|
Typically UNIX domain sockets are created with more liberal
file permissions than the rest of the application. By default,
we create UNIX domain sockets to be readable and writable by
all local users to give them the same accessibility as
locally-bound TCP listeners.
This only has an effect on UNIX domain sockets.
This was inspired by Suraj Kurapati in
cfbcd2f00911121536rd0582b8u961f7f2a8c6e546a@mail.gmail.com
|
|
Some of this based on Suraj Kurapati's comments on
the mailing list.
|
|
This must be called in the after_fork hook because there may be
Ruby modules that'll allow things such as CPU affinity and
scheduling class/priority to be set on a per-worker basis. So
we give the user the ability to change users at any time during
the after_fork hook.
|
|
We follow the principle of least surprise now, so less
documentation is better documentation.
|
|
It makes more sense this way since users usually expect config
file directives to be order-independent.
|
|
Just in case anything depends on it, we'll have it set
correctly because it's usually set by the $SHELL
|
|
Allow people to use "~" and relative paths, like all
of our other paths.
|
|
This basically a prettier way of saying:
Dir.chdir(Unicorn::HttpServer::START_CTX[:cwd] = path)
In the config file. Unfortunately, this is configuration
directive where order matters and you should specify it
before any other path[1] directives if you're using relative
paths (relative paths are not recommended anyways)
[1] pid, stderr_path, stdout_path
|
|
Thanks to Greg Melton for reporting.
|
|
also __FILE__ did not reflect configuration file path
|