| 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
|
|
The HttpParser#next? method will come with keepalive protection
for Rainbows!, which can prevent clients from monopolizing a
server with excessive pipelining/keepalive requests.
|
|
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.
|
|
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.
|
|
This is only needed for concurrency options that
do not use TeeInput, since TeeInput automatically
handles this for us.
|
|
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.
|
|
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
|
|
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.
|
|
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.
|
|
These allow for small reductions in the amount of variables
we have to manage, more changes coming with later Unicorns.
|
|
For consistency, changed settings are reset back to
their default values if they are removed or commented
out from the config file.
|
|
Mostly internal changes for kgio (and Unicorn) integration.
There should be no (supported) user-visible changes from
Rainbows! 0.97.0. kgio should improve performance for
concurrency models that use non-blocking I/O internally,
especially under Ruby 1.9.2
|
|
Once again we avoid documenting internals on the public
website and use code comments for other developers.
|
|
kgio_trywrite is superior if it is available.
|
|
It does not appear to be needed, for now, since the
parser and Unicorn::HttpRequest are one and the same.
|
|
This simplifies and disambiguates most constant resolution
issues as well as lowering our identation level. Hopefully
this makes code easier to understand.
|
|
Applications may use wait_readable-aware methods directly
to work with Rainbows!
|
|
Reduces confusion for constant resolution/scoping rules
and lowers LoC.
|