| Date | Commit message (Collapse) |
|---|
|
Cool.io (new version of Rev) support is explicitly added
(it always worked before). ":Coolio" may be used in place
of ":Rev" anywhere in your Rainbows! config file.
There is a new "keepalive_requests" config directive to limit
the number of requests a single connection may make (default:
100, same as nginx). This may be useful for better
load-balancing characteristics.
The old "Rev" prefixes remain supported as long as Cool.io
remains compatible with Rev (likely forever).
Bug fixes:
* Rainbows::ThreadTimeout middleware with multiple clients
* large, pipelined upload errors with Revactor+Coolio(Rev)
* high CPU usage for maintaining idle keepalive on *Fiber*
* needless ThreadPool wakeups
* request env prematurely cleared keepalive requests,
breaking some middlewares such as Clogger.
* "close" not called on body if wrapper and sendfile used together
Various code cleanups, and our RDoc website is JavaScript-free.
See the ChangeLog or git for all changes.
|
|
We use Cool.io internally everywhere now, but preserve
Rev-based models for anybody using them.
|
|
Some middlewares require the Rack env to be preserved all
the way through to close, so we'll ensure all request models
preserve it.
We also need to better response body wrappers/proxies always get
fired properly when returning. IO.copy_stream and "sendfile"
gem users could hit cases where wrappers did not fire properly.
|
|
No need to wrap regular files
|
|
This will allow servers to limit the number of keepalive
requests that can be made over a single connection to
prevent denial-of-service and also to improve fairness
in load-balancing.
|
|
We still use and define Rev internally, but that's
mostly just manual labor of converting stuff over.
|
|
Blindly resuming fibers every second is a waste of cycles, we
can use the ZZ hash in regular FiberSpawn to resume expired
fibers on an as-needed basis.
While we're at it, merge the keepalive-timeout class into the
heartbeat, there's no reason to have separate timers and
classes here.
|
|
This is also our website, so we need to document the new
Cool.io-based concurrency options for users and point
existing Rev* users to it.
|
|
Cool.io is the new name for Rev. We'll continue to support Rev
until Cool.io breaks backwards compatibility. Rev may not be
supported if Cool.io is.
|
|
It's slightly faster this way, but string slicing sucks
anyways :<
|
|
We can use the same interface as Rainbows::Fiber.sleep to avoid
blindly waking up readers at ever scheduler invocation.
|
|
Less visual noise
|
|
No point in waking up when our ticker runs in a separate
thread.
|
|
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).
|