| Date | Commit message (Collapse) |
|---|
|
It seems to basically work, this is based heavily on the
Revactor one...
|
|
Make sure app errors get logged correctly, and we no longer
return a 500 response when a client EOFs the write end (but not
the read end) of a connection.
|
|
This enables the safe use of Rainbows::AppPool with all
concurrency models, not just threaded ones. AppPool is now
effective with *all* Fiber-based concurrency models including
Revactor (and of course the new Fiber{Pool,Spawn} ones).
|
|
This is another Fiber-based concurrency model that can exploit
a streaming "rack.input" for clients. Spawning Fibers seems
pretty fast, but maybe there are apps that will benefit from
this.
|
|
This one seems a easy to get working and supports everything we
need to support from the server perspective. Apps will need
modified drivers, but it doesn't seem too hard to add
more/better support for wrapping IO objects with Fiber::IO.
|
|
|
|
And change the default to 2 seconds, most clients can
render the page and load all URLs within 2 seconds.
|
|
Seems to pass all tests, but that may only mean our
test cases are lacking...
|
|
It turns out neither the EventMachine and Rev classes
checked for master death in its heartbeat mechanism.
Since we managed to forget the same thing twice, we
now have a test case for it and also centralized the
code to remove duplication.
|
|
Working for simple GET requests, completely untested otherwise
and most definitely not able to handle async/Comet-style
requests yet, either. No tests for this are enabled.
This could share a lot of code with the existing Rev model.
|
|
This new middleware should be a no-op for non-Rev concurrency
models (or by explicitly setting env['rainbows.autochunk'] to
false).
Setting env['rainbows.autochunk'] to true (the default when Rev
is used) allows (e)poll-able IO objects (sockets, pipes) to be
sent asynchronously after app.call(env) returns.
This also has a fortunate side effect of introducing a code path
which allows large, static files to be sent without slurping
them into a Rev IO::Buffer, too. This new change works even
without the DevFdResponse middleware, so you won't have to
reconfigure your app.
This lets us epoll on response bodies that come in from a pipe
or even a socket and send them either straight through or with
chunked encoding.
|
|
We use the "G" global constant from the Rev model everywhere
to simplify things a little.
Test cases are more consistent now, too.
|
|
|
|
There is no TeeInput (streaming request body) support, yet,
as that does not seem fun nor easy to do (or even possible
without using Threads or Fibers or something to save/restore
the stack...)
|
|
|
|
Only inject this method into Unicorn::Configurator to avoid
polluting the namespace.
|
|
Various concurrency models work and scale differently, pick
counts that make a reasonable amount of sense...
|
|
This is somewhat like the original model found in Mongrel,
except we refuse to accept() connections unless we have slots
available. Even though we support multiple listen sockets, we
only accept() synchronously to simplify processing and to avoid
having to synchronize ThreadGroup management.
|
|
They're similar enough (especially as far as the constants go)
and allows a :Base to be used which basically acts like plain
Unicorn but with HTTP keepalive + pipelining support
|
|
This allows the server to be configured by doing something like
this inside an existing Unicorn configuration file:
Rainbows! do
use :Revactor
worker_connections 50
end
This should make it obvious we're using Rainbows-only features.
|
|
No tests yet, but the old "gossamer" and "rainbows" branches
seem to be basically working.
|