| Date | Commit message (Collapse) |
|---|
|
Hopefully this will make our code easier to follow.
|
|
This lets Rainbows! yield the current worker process
when busy in the hopes another worker will pick up the
slack. We can also override this for the single worker
process case later if people care enough.
|
|
Self-documenting code is easier to follow
|
|
Use a consistent "Client" naming to reduce confusion
|
|
Needless duplication sucks
|
|
|
|
Some applications never need TeeSocket, and we don't have
to worry about thread-safety with Revactor.
|
|
This should make things easier on the eyes.
|
|
This also cleans up some constant resolution for the root
Fiber class.
|
|
It's ugly to look at.
|
|
alias_method is a mess, super is superb!
|
|
This should make things easier to find
|
|
This should make classes easier to find and hopefully make
our code easier to follow.
|
|
One line of code saved! We'll also avoid loading
DeferredChunkResponse which is rarely needed
(unlike DeferredResponse).
|
|
While we're at it, unindent
|
|
It still burns CPU at the first sign of doing anything
interesting, so stop it. Ruby 1.9 is the future :P
|
|
Oops
|
|
The HttpParser#next? method will come with keepalive protection
for Rainbows!, which can prevent clients from monopolizing a
server with excessive pipelining/keepalive requests.
|
|
Unicorn 3.2.1 gives us an improved HttpParser#next? that
preserves state until the next HttpParser#parse call.
|
|
This makes constant resolution more predictable, we hope.
|
|
One file per class/module should be easier for new
hackers to find. Unindent rainbows/rev/core while
we're at it, too.
|
|
Deferred* classes will get loaded anyways since
Rainbows::Rev::Client hit them in case statements.
|
|
It is a common base so we can share documentation tasks
more easily with Unicorn and it ensures our RDoc no longer
has JavaScript in it!
|
|
This was causing unrelated requests to get killed every
+timeout+ seconds, instead of only the ones that were
running too long.
Noticed-by: ghazel@gmail.com
ref:
http://mid.gmane.org/AANLkTi=7OhyTwkHsp_rXU7Gp1PokihiQ9bJigpO-BfN6@mail.gmail.com
|
|
Because of the lack of GVL-releasing syscalls in this branch
of the thread loop, we need Thread.pass to ensure other threads
get scheduled appropriately under 1.9. This is likely a threading
bug in 1.9 that warrants further investigation when we're in a
better mood.
|
|
At least one user ran into it:
http://mid.gmane.org/AANLkTikegPX2-6Q93++bz_aLt+9nLPJXjg+NkL8tDjeE@mail.gmail.com
|
|
This is only needed for concurrency options that
do not use TeeInput, since TeeInput automatically
handles this for us.
|
|
We'll be taking advantage of configurable
client_buffer_body_size soon.
|
|
Avoid exposing internals, it's also slightly faster to
access ivars directly rather than using method calls.
|
|
This was completely overlooked for the Rainbows 2.0.x
releases.
|
|
We use real tabs for indenting shell code since it is not Ruby.
|
|
Large uploads behave differently with regard to buffering,
and there were bugs in the way the Rev and Revactor backends
handled uploads.
|
|
For HTTP clients living on the edge and pipelining uploads, we
now fully support pipelined requests (as long as the application
consumes each request in its entirety).
|
|
All synchronous models have this fixed in unicorn 3.0.1,
so only Rev and EventMachine-based concurrency models
require code changes.
|
|
Hopefully it makes more sense now and is easier to
digest for new hackers.
|
|
We may have other uses for this in the future...
|
|
This release is targeted at the minority of web applications
that deal heavily with uploads.
Thanks to Unicorn 3.x, we now support HTTP keepalive for
requests with bodies as long as the application consumes them.
Unicorn 3.x also allows disabling the rewindability requirement
of "rack.input" (in violation of the Rack 1.x spec).
The global client_body_max_size may also be applied per-endpoint
using the Rainbows::MaxBody middleware described in:
http://rainbows.rubyforge.org/Rainbows/MaxBody.html
|
|
Unicorn 3.0.0 is final and released, so we will use it in our
tests
|
|
Oops, last commit was rushed
|
|
Unicorn 3.x includes HttpParser#next? which will reset the
parser for keepalive requests without extra steps.
|
|
To avoid denial-of-service attacks, the wrappers need to
intercept requests *before* they hit the memory allocator, so we
need to reimplement the read(all) and gets cases to use
smaller buffers whenever the application does not specify one.
|
|
Those already use CapInput, just like the rest of the evented
Rainbows! world.
|
|
Kgio 2.0.0 has a superior API and less likely to conflict or
blow up with other applications. Unicorn 3.x requires Kgio 2.x,
too.
|
|
It allows disabling rewindable input and contains
simpler code for upload processing.
|
|
This allows the client_max_body_size implementation to not rely
on Unicorn::TeeInput internals, allowing it to be used with
Unicorn::StreamInput (or any other (nearly)
Rack::Lint-compatible input object).
|
|
Errno::EAGAIN is still a problem under Ruby 1.9.2, so try harder
to avoid it and use kgio methods. Even when 1.9.3 is available,
kgio will still be faster as exceptions are slower than normal
return values.
|
|
The underlying symbolic names are easier to type and
recommended.
|
|
The long-term goal is to make the Unicorn API more terse when
handling keepalive.
|
|
This release is merely a milestone in our evolving internal API.
Use of kgio may result in performance improvements under Ruby
1.9.2 with non-blocking I/O-intensive workloads.
The only bugfix is that SIGHUP reloads restores defaults on
unset settings. A similar fix is included in Unicorn 2.0.0
as well.
|
|
We need to ensure the old worker is really dead before sending
requests after reloading.
|