Date | Commit message (Collapse) |
|
We now rely on Unicorn 4.0.0. We'll use the latest
kgio and raindrops versions anyways.
|
|
It hasn't been used in a while, but we kept it for
Zbatery version compatibility.
|
|
Some pipe responses can trigger the on_deferred_write_complete
method without ever re-running the event loop.
This appears to be the result of the occasional t0050 failures.
|
|
This test seems to fail sometimes with Epoll and XEpoll...
|
|
That's been around forever, and we think Rubinius supports
that...
|
|
Untested, but it should work nowadays...
|
|
This removes the extra per-process file descriptor and
replaces it with Raindrops.
|
|
It's already a runtime dependency
|
|
We no longer need to put all listeners away since
Unicorn uses kgio.
|
|
Lowering this will lower worst-case memory usage and mitigate some
denial-of-service attacks. This should be larger than
client_header_buffer_size.
The default value is carried over from Mongrel and Unicorn.
|
|
Do not encourage their use, really.
|
|
Yes, this concurrency model is our strangest yet.
|
|
We can get away with a single stack frame reduction. Unicorn
itself has more stack reductions, but Rainbows! is further
behind in this area.
|
|
Do not assume middlewares/applications are stupid and blindly
add chunking to responses (we have precedence set by
Rack::Chunked).
|
|
HttpParser#trailers and #headers are actually the same
method, so we'll just continue on.
|
|
Reduces inconsistency.
|
|
It's easier-to-use in some cases.
|
|
Oops.
|
|
Rack::File already sets Content-Range, so don't repeat work
and reparse Content-Length.
|
|
We send HEAD requests and expect body-less responses.
Noticed while running a newer rack version after re-isolating.
|
|
Gotta keep using the latest and greatest.
|
|
This doesn't use Rainbows::Base so we have no keepalive support
at all. This could eventually be an option for streaming
applications.
|
|
We may not always use Rainbows! :Base since we don't want
keepalive/immediate log reopening in some cases.
|
|
pandoc 1.8 no longer supports this, and we don't need it anyways
since we only generate documentation from our repository.
|
|
Linux 3.0.0 is just around the corner and of course newer
than 2.6.
|
|
The latest Linux series is now 3.x, not 2.6.x
|
|
SIGQUIT (graceful shutdown) now drops idle keepalive clients for
the concurrency models where maintaining an idle client is
relatively inexpensive: Coolio, CoolioThreadPool,
CoolioThreadSpawn, Epoll, EventMachine, XEpoll,
XEpollThreadPool, XEpollThreadSpawn.
Kgio.autopush now works properly for all multi-threaded
concurrency models (if you're using :tcp_nopush).
|
|
* locale fix for grep
|
|
It's better under 1.9.3 (sleepy_penguin 3.0.1 was bogus)
|
|
It's better under 1.9.3
|
|
|
|
It should hopefully give this more visibility even though it's
an internal feature.
|
|
We need to trigger a recv() to uncork the response.
This won't affect fairness (much) since all recv()s
are non-blocking and a successful header parse will
put us in the back of the queue.
|
|
Some folks use them.
|
|
We can support it fully for a subset of concurrency models where
we have full control over buffering and HTTP/1.1 keepalive
clients.
|
|
This will only be supported for certain concurency models, but
it's probably good enough.
|
|
Since it's cheap to maintain keepalive clients with EM, we need
a way of disconnecting them in a timely fashion on rare SIGQUIT
events.
|
|
This should enable Kgio "autopush" support for ThreadSpawn,
ThreadPool, XEpollThreadSpawn, and XEpollThreadPool.
(still needs tests)
|
|
In concurrency models long keepalive times are cheap (and thus
more likely to be used), this allows Rainbows! to gracefully
shut down more quickly.
|
|
There's less logic in the server this way and easier
to potentially share code this way.
|
|
io_splice 4.1.1 works around issues with socket
buffers filling up pipe buffers on blocking splice.
See http://lkml.org/lkml/2009/1/13/478 for a better
explanation.
|
|
* improved documentation all around, suggestions/comments to further
improve documentation is greatly welcome at: rainbows-talk@rubyforge.org
* added GPLv3 option to the license (now (Ruby|GPLv2|GPLv3), though
Unicorn is still (Ruby|GPLv2) for now)
* added client_header_buffer_size config directive (default 1K)
* small default header buffer size (16K => 1K) to reduce memory usage,
Rails apps with cookie sessions may want to increase this (~2K)
* all concurrency models default to 50 connections per process
* all concurrency models with a secondary :pool_size parameter also
default to 50 (threads/fibers/whatever)
* RLIMIT_NOFILE and RLIMIT_NPROC are automatically increased if needed
* Rainbows::ThreadTimeout middleware rewritten, still not recommended,
lazy people should be using Unicorn anyways :)
* Several experimental Linux-only edge-triggered epoll options:
XEpollThreadSpawn, XEpollThreadPool, XEpoll, and Epoll.
The latter two were in previous releases but never announced.
These require the "sleepy_penguin", "raindrops", and "sendfile" RubyGems
=== Deprecations
* Rainbows::Fiber::IO* APIs all deprecated, Rainbows! will avoid
having any concurrency model-specific APIs in the future and
also avoid introducing new APIs for applications.
* Fiber-based concurrency models are no longer recommended, they're
too fragile for most apps, use at your own risk (they'll continue to
be supported, however). Linux NPTL + Ruby 1.9 is pretty lightweight
and will be even lighter in Ruby 1.9.3 if you're careful with stack
usage in your C extensions.
|
|
I can't wait until I stop supporting Ruby 1.8
|
|
Hopefully makes things easier to try out.
|
|
The only supported method is Rainbows.sleep in here
|
|
Only needed for Ruby 1.9
|
|
Just close the epoll descriptor, since the sleepy_penguin
epoll_wait wrapper may not return EINTR in the future.
|
|
This makes things easier to maintain as we add more concurrency
options.
|
|
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).
|
|
Finally, we have all methods in configurator and it's
much easier to document!
|