| Date | Commit message (Collapse) |
|---|
|
Only needed for Ruby 1.9
|
|
This allows using IO::Splice.copy_stream from the "io_splice"
RubyGem on recent Linux systems. This also allows users to
disable copy_stream usage entirely and use traditional
response_body.each calls which are compatible with all Rack
servers (to workaround bugs in IO.copy_stream under 1.9.2-p180).
|
|
There's actually no reason we can't have these methods
in Rainbows::Configurator where it's easier to document
nowadays.
|
|
It *can* have as many threads as it does idle connections.
|
|
We won't forget to reset defaults on SIGHUP anymore.
|
|
Too confusing otherwise...
|
|
We're changing our default to 1K buffers to save memory. This
should reduce memory usage of idle clients and lower pressure on
the MRI GC. Rails applications using session cookies (the
default) may want to up this to 2K or more.
|
|
pavinging the way for changing MODEL_WORKER_CONNECTIONS
|
|
Might as well, threads are free and cheap on 64-bit
|
|
In case people try to do C10K, make life easier for them.
|
|
Ugh the old way was gross.
|
|
Run under 1.9.3dev
|
|
Actually use the Rainbows::O constant for use
[ew: rewritten commit message subject]
Acked-by: Eric Wong <normalperson@yhbt.net>
|
|
Ugh, I need to think of a way to clean this up...
|
|
It's too long especially since XEpollThreadPool is planned :>
|
|
Edge-triggered epoll concurrency model with blocking accept() in
a (hopefully) native thread. This is recommended over Epoll for
Ruby 1.9 users as it can workaround accept()-scalability issues
on multicore machines.
|
|
Coolio and EventMachine only use level-triggered epoll,
but being Rainbows!, we live on the EDGE!
|
|
Code organization is hard :<
|
|
Easier just to use an instance variable
|
|
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.
|
|
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.
|
|
For consistency, changed settings are reset back to
their default values if they are removed or commented
out from the config file.
|
|
This simplifies and disambiguates most constant resolution
issues as well as lowering our identation level. Hopefully
this makes code easier to understand.
|
|
We get basic internal API changes from Unicorn,
code simplifications coming next.
|
|
Sometimes we have stupid syntax or constant resolution
errors in our code.
|
|
Since we suck at building websites, we just rely on RDoc as a
website builder. And since Rainbows! is an application server
(and not a programming library), our internal API should be of
little interest to end users.
Anybody interested in Rainbows! (or any other project) internals
should be reading the source.
|
|
Array#[] lookups are slightly faster under both rbx and 1.9,
and easier to read.
|
|
duh!
|
|
Since we have conditional deferred execution in the regular
EventMachine concurrency model, we can drop this one.
This concurrency model never fully worked due to lack of
graceful shut downs, and was never promoted nor supported, either.
|
|
Since Rainbows! is supported when exposed directly to the
Internet, administrators may want to limit the amount of data a
user may upload in a single request body to prevent a
denial-of-service via disk space exhaustion.
This amount may be specified in bytes, the default limit being
1024*1024 bytes (1 megabyte). To override this default, a user
may specify `client_max_body_size' in the Rainbows! block
of their server config file:
Rainbows! do
client_max_body_size 10 * 1024 * 1024
end
Clients that exceed the limit will get a "413 Request Entity Too
Large" response if the request body is too large and the
connection will close.
For chunked requests, we have no choice but to interrupt during
the client upload since we have no prior knowledge of the
request body size.
|
|
http_response and http_server are never NOT loaded when
"rainbows" is required.
|
|
There's a good chunk of tests that fail with this, still.
Worse, I haven't been able to figure out what's wrong since
it looks like it would involve looking at C++ code...
|
|
|
|
Eventually we hope to be able to accept arguments like
the way Rack handlers do it:
use :Foo, :bool1, :bool2, :option => value
|
|
And change the default to 2 seconds, most clients can
render the page and load all URLs within 2 seconds.
|
|
This reverts commit e1dcadef6ca242e36e99aab19e3e040bf01070f9.
This is fixed separately in Unicorn 0.95.0 (commit
560216c2fecfc5cf3489f749dc7a0221fd78eb26)
|
|
Permissions for the logs could've been badly set by the master.
So we we'll let the master reopen them and refork children to
get around this problem. We have to be more careful when
reopening logs because we can reopen them in the middle of
client requests (we have to) whereas Unicorn has the luxury
of _knowing_ it has no active clients when it does the reopen.
|
|
It's already global...
|
|
Loading TeeInput or HttpResponse late does not always work well
in multithreaded situations and have been causing random test
failures on heavily loaded multicore boxes.
|
|
This is because our timeout implementations are less precise
than Unicorn. Since we handle multiple clients with the same
process, we sacrifice precision for performance and instead
implement our fchmod heartbeats at a fixed rate, as doing
fchmod() repeated for short-lived connections would hurt
performance and we have to call fchmod even when connected
clients are idle.
|
|
Since const_get works with a string as well as a symbol,
allow that to be used. It's easier and simpler to just
allow strings as use arguments than to error check and
raise exceptions.
So both of the following should now work:
Rainbows! do
use :Revactor
end
Rainbows! do
use "Revactor"
end
Rainbows! will always use the symbol variant internally,
however, so applications can alway expect env['rainbows.model']
to be a symbol.
|
|
This means Rainbows::DevFdBody async responses and large
file streaming without slurping.
This is only with eventmachine 0.12.8, it looks like 0.12.10
changes the attach/watch API...
|
|
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.
|
|
It's more fool-proof this way and prevents us from using
idiotic/non-obvious concurrency model names.
|
|
This allows applications to determine which concurrency model
they're running under and possibly make adjustments accordingly.
The standard "rack.multithread" isn't enough for some
applications to determine what to do, especially when reentrancy
is required/recommended.
|
|
Various concurrency models work and scale differently, pick
counts that make a reasonable amount of sense...
|
|
:Base is default (along with the implied worker_connections=1).
This disallows nil for worker_connections, and makes.
|
|
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.
|
|
I didn't remember extend when this was originally implemented.
|
|
No tests yet, but the old "gossamer" and "rainbows" branches
seem to be basically working.
|