Date | Commit message (Collapse) |
|
Despite the version number, this release mostly features
internal cleanups for future versions of Rainbows!. User
visible changes include reductions in CPU wakeups on idle sites
using high timeouts.
Barring possible portability issues due to the introduction of
the kgio library, this release should be ready for all to use.
However, 1.1.x (and possibly 1.0.x) will continue to be
maintained. Unicorn 1.1.5 and 1.0.2 have also been released
with bugfixes found during development of 2.0.0.
|
|
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.
|
|
To reduce CPU wakeups and save power during off hours,
we can precalculate a safe amount to sleep before killing
off idle workers.
|
|
If a moronic sysadmin is sending too many signals, just let them
do it. It's likely something is terribly wrong when the server
is overloaded with signals, so don't try to protect users from
it. This will also help in case where TTOU signals are sent too
quickly during shutdown, although sleeping between kill(2)
syscalls is always a good idea because of how non-real-time
signals are delivered.
|
|
There is a new Unicorn::PrereadInput middleware to which allows
input bodies to be drained off the socket and buffered to disk
(or memory) before dispatching the application.
HTTP Pipelining behavior is fixed for Rainbows! There
are some small Kgio fixes and updates for Rainbows!
users as well.
|
|
This may be useful for some apps that wish to drain the body
before acquiring an app-wide lock. Maybe it's more useful
with Rainbows!...
|
|
Internal changes/cleanups for Rainbows!
|
|
This should be easier for Rainbows! to use
|
|
We clobber the accessor methods.
|
|
Mostly internal cleanups for future versions of Rainbows! and
people trying out Rubinius. There are tiny performance
improvements for Ruby 1.9.2 users which may only be noticeable
with Rainbows!
Unicorn 1.1.x users are NOT required to upgrade.
|
|
This also affects some constant scoping rules, but hopefully
makes things easier to follow. Accessing ivars (not via
accessor methods) are also slightly faster, so use them in
the criticial process_client code path.
|
|
This provides the kgio_read! method which is like readpartial,
only significantly cheaper when a client disconnects on us.
|
|
TeeInput methods may be invoked deep in the stack, so
avoid giving them more work to do if a client disconnects
due to a bad upload.
|
|
This is for compatibility with Ruby implementations such as
Rubinius that use "IO.new" internally inside "IO.open"
|
|
Thanks to kgio, we no longer use accept_nonblock.
|
|
This hopefully makes things easier to read and follow.
|
|
This is slightly shorter and hopefully easier to find.
|
|
This should hopefully make the non-blocking accept()
situation more tolerable under Ruby 1.9.2.
|
|
This hides more HTTP request logic inside our object.
|
|
This should ensure we have less typing to do.
|
|
Rainbows! will be able to reuse this.
|
|
This hopefully makes things easier to read, follow, and find
since it's mostly documentation...
|
|
There's no need for a response class or object since Rack just
uses an array as the response. So use a procedural style which
allows for easier understanding.
We shall also support keepalive/pipelining in the future, too.
|
|
While we've always unlinked dead sockets from nuked/leftover
processes, blindly unlinking them can cause unnecessary failures
when an active process is already listening on them. We now
make a simple connect(2) check to ensure the socket is not in
use before unlinking it.
Thanks to Jordan Ritter for the detailed bug report leading to
this fix.
ref: http://mid.gmane.org/8D95A44B-A098-43BE-B532-7D74BD957F31@darkridge.com
|
|
These nasty hacks were breaking Rubinius compatibility.
This can be further cleaned up, too.
|
|
A follow-up to 4b23693b9082a84433a9e6c1f358b58420176b27
If multithreaded programming can be compared to juggling
chainsaws, then multithreaded programming with signal handlers
in play is akin to juggling chainsaws on a tightrope
over shark-infested waters.
|
|
IOError may occur due to race conditions as another thread
may close the file immediately after we call File#closed?
to check.
Errno::EBADF may occur in some applications that close a file
descriptor without notifying Ruby (or if two IO objects refer to
the same descriptor, possibly one of them using IO#for_fd).
|
|
These are minor changes to remove unnecessary loop nesting and
begin usage to reduce our code size and hopefully simplify
flow for readers.
|
|
Something is wrong if workers exit with a non-zero status,
so we'll increase the log level to help prevent people
from missing it.
|
|
In addition to SIGHUP, it should be possible to gradually bring
workers back up (to avoid overloading the machine) when rolling
back upgrades after SIGWINCH.
Noticed-by: Lawrence Pit
ref: http://mid.gmane.org/4C3F8C9F.2090903@gmail.com
|
|
As described in our SIGNALS documentation, sending SIGHUP to the
old master (to respawn SIGWINCH-ed children) while the new
master (spawned from SIGUSR2) is active is useful for backing
out of an upgrade before sending SIGQUIT to the new master.
Unfortunately, the SIGHUP signal to the old master will cause
the ".oldbin" pid file to be reset to the non-".oldbin" version
and thus attempt to clobber the pid file in use by the
to-be-terminated new master process.
Thanks to the previous commit to prevent redaemonization in the
new master, the old master can reliably detect if the new master
is active while it is reloading the config file.
Thanks to Lawrence Pit for discovering this bug.
ref: http://mid.gmane.org/4C3BEACF.7040301@gmail.com
|
|
This was accidentally enabled when ready_pipe was developed.
While re-daemonizing appears harmless in most cases this makes
detecting backed-out upgrades from the original master process
impossible.
|
|
Noticed while hacking on a Zbatery-using application
|
|
"stringio" is part of the Ruby distro and we use it in multiple
places, so avoid re-requiring it.
|
|
"[]" is slightly faster under Ruby 1.9 (but slightly
slower under 1.8).
|
|
Different threads may change $/ during execution, so cache it at
function entry to a local variable for safety. $/ may also be
of a non-binary encoding, so rely on Rack::Utils.bytesize to
portably capture the correct size.
Our string slicing is always safe from 1.9 encoding: both our
socket and backing temporary file are opened in binary mode,
so we'll always be dealing with binary strings in this class
(in accordance to the Rack spec).
|
|
|
|
Instead of detecting at startup if filters may be used, just try
anyways and log the error. It is better to ask for forgiveness
than permission :)
|
|
We only use this module in HttpServer and our unit test mocks
it properly.
|
|
No point in redeclaring the Unicorn module in here.
|
|
The defaults should be reasonable, but there may be
folks who want to experiment.
|
|
This is to allow Rainbows! to override the defaults.
|
|
Under Linux, this allows users to tune the time (in seconds) to
defer connections before allowing them to be accepted. The
behavior of TCP_DEFER_ACCEPT changed with Linux 2.6.32 and idle
connections may still be accept()-ed after the specified value
in seconds. A small value of '1' remains the default for
Unicorn as Unicorn does not worry about slow clients. Higher
values provide better DoS protection for Rainbows! but also
increases kernel memory usage.
Allowing "dataready" for FreeBSD accept filters will allow
SSL sockets to be used in the future for HTTPS, too.
|
|
This affects Rainbows!, but Rainbows! is still using the Unicorn
1.x branch. While we're at it, avoid redeclaring the "Unicorn"
module, it makes documentation noisier.
|
|
|
|
It makes RDoc look better and cleaner, since we don't
do anything in the Unicorn namespace.
|
|
Some folks may require more fine-grained control of buffering
and I/O chunk sizes, so we'll support them (unofficially, for
now).
|
|
no need to pass an extra argument
|