| Date | Commit message (Collapse) |
|---|
|
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
|
|
It has come to our attention that this setting is not very
well-known to the rest of the world...
|
|
:delay may be a Float to represent fractional seconds.
|
|
We now give an example of how a before_fork hook can be used
to incrementally migrate off the old code base without hitting
a thundering herd (especially in the "preload_app false") case.
Also comment on the per-worker listen usage in the RDoc, not
just a hidden comment.
|
|
We no longer have external lookups for it so just stick it in
the DEFAULTS hash for now. Since the Configurator::DEFAULTS
hash can be considered a stable interface for other modules to
interact with, they can eventually just use it instead of
relying on another constant.
|
|
Hopefuly make it more obvious that they're Ruby symbols and not
strings. While we're at it, fix ordering of :{rcv,snd}buf
descriptions to (logically) match the order of mention.
|
|
* Use the new :tries and :default parameters for listen()
instead of the ugly and less-effective "rescue nil"
* ActiveRecord connection management examples for hooks when
using for "preload_app true"
* combine "preload_app true" example with REE COW-friendly
optimization for memory savings
Some of these are based on Chris Wanstrath's configuration
posted here: http://gist.github.com/189623
|
|
Avoids making the #listen method any noisier than it should be.
|
|
This may be redundant for the "normal" configuration file
directive, but allows the same syntax to be used in after_fork
hooks where HttpServer#listen() may be called.
|
|
This allows per-worker listeners to be configured to retry and
and not continue until the equivalent worker belonging to a
previous master (or even another server) has released the
socket.
In the Configurator RDoc, include better examples for
per-worker server.listen calls using these :tries == -1.
Inspired by an example by Chris Wanstrath.
|
|
We changed this in 97e469fc3afb751618b8b9a7b364cb447aaf90dd
but never updated the example.
|
|
This ensures any string literals that pop up in *our* code will
just be a bag of bytes. This shouldn't affect/fix/break
existing apps in most cases, but most constants will always have
the "correct" encoding (none!) to be consistent with HTTP/socket
expectations. Since this comment affects things only on a
per-source basis, it won't affect existing apps with the
exception of strings we pass to the Rack application.
This will eventually allow us to get rid of that Unicorn::Z
constant, too.
|
|
There's a small memory reduction to be had when forking
oodles of processes and the Perl hacker in me still
gets confused into thinking those are arrays...
|
|
This change gives applications full control to deny clients
from uploading unwanted message bodies. This also paves the
way for doing things like upload progress notification within
applications in a Rack::Lint-compatible manner.
Since we don't support HTTP keepalive, so we have more freedom
here by being able to close TCP connections and deny clients the
ability to write to us (and thus wasting our bandwidth).
While I could've left this feature off by default indefinitely
for maximum backwards compatibility (for arguably broken
applications), Unicorn is not and has never been about
supporting the lowest common denominator.
|
|
Now that we support tunnelling arbitrary protocols over HTTP as
well as "100 Continue" responses, TCP_NODELAY actually becomes
useful to us. TCP_NODELAY is actually reasonably portable
nowadays; even.
While we're adding non-portable options, TCP_CORK/TCP_NOPUSH can
be enabled, too. Unlike some other servers, these can't be
disabled explicitly/intelligently to force a flush, however.
However, these may still improve performance with "normal" HTTP
applications (Mongrel has always had TCP_CORK enabled in Linux).
While we're adding OS-specific features, we might as well
support TCP_DEFER_ACCEPT in Linux and FreeBSD the "httpready"
accept filter to prevent abuse.
These options can all be enabled on a per-listener basis.
|
|
The default is false because some applications were not
written to handle partial reads (even though IO#read allows
it, not just IO#readpartial).
|
|
2 seconds is still prone to race conditions under high load.
We're intentionally less accurate than we could be in order to
reduce syscall and method dispatch overhead.
|
|
|