Date | Commit message (Collapse) |
|
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"
|
|
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).
|
|
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
|
|
There are only minor changes since 0.991.0.
For users clinging onto the past, MRI 1.8.6 support has been
restored. Users are strongly encouraged to upgrade to the
latest 1.8.7, REE or 1.9.1.
For users looking towards the future, the core test suite and
the Rails 3 (beta) integration tests pass entirely under 1.9.2
preview3. As of the latest rubinius.git[1], Rubinius support is
nearly complete as well.
Under Rubinius, signals may corrupt responses as they're being
written to the socket, but that should be fixable transparently
to us[4]. Support for the hardly used, hardly documented[2]
embedded command-line switches in rackup config (.ru) files is
is also broken under Rubinius.
The recently-released Rack 1.2.1 introduced no compatiblity
issues[3] in core Unicorn. We remain compatible with all Rack
releases starting with 0.9.1 (and possibly before).
[1] tested with Rubinius upstream commit
cf4a5a759234faa3f7d8a92d68fa89d8c5048f72
[2] lets avoid the Dueling Banjos effect here :x
[3] actually, Rack 1.2.1 is broken under 1.8.6.
[4] http://github.com/evanphx/rubinius/issues/373
|
|
While log reopening worked reliably for newly-created File
objects in the unit tests, the $stderr and $stdout handles that
get redirected did not get reopened reliably under Rubinius.
We work around this by relying on Rubinius internals and
directly setting the @path instance variable. This is harmless
for MRI and should be harmless for other any other Ruby
implementations we'll eventually support.
ref: http://github.com/evanphx/rubinius/issues/360
|
|
Rack 1.2 removed the +size+ method requirement, but we'll
still support it since Rack 1.2 doesn't _prohibit_ it, and
Rack 1.[01] applications will continue to exist for a while.
|
|
Rack 1.2 no longer requires "rack.input" objects respond
to size.
|
|
No point in having namespaces be classes when we never
create instances of them...
|
|
The "working_directory" configuration parameter is now handled
before config.ru. That means "unicorn" and "unicorn_rails" no
longer barfs when initially started outside of the configured
"working_directory" where a config.ru is required. A huge
thanks to Pierre Baillet for catching this ugly UI inconsistency
before the big 1.0 release
Thanks to Hongli Lai, out-of-the-box Rails 3 (beta) support
should be improved for deployments lacking a config.ru
There are more new integration tests, cleanups and some
documentation improvements.
|
|
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
|
|
Rainbows! and Zbatery have long been upgraded to
pass options to us.
|