Date | Commit message (Collapse) |
|
There are only some minor cleanups in this release and a bump to
kgio 2.5 to remove the dependency on io/wait. kgio 2.5 or later
is now required (kgio 2.6+ will be required in the next
release).
|
|
Unicorn 4.x already defaults match those of Rainbows!
to favor lower latency instead of lowered bandwidth
usage.
|
|
kgio 2.5 added kgio_wait_*able methods
|
|
Unicorn (> 4.0.1) already handles this for us,
not that it affects many people...
This reverts commit 37c376a9253ed62d134cbb4dbc6eaecc6076c77e.
|
|
Race conditions abound in the world of concurrency!
|
|
This fixes up breakage introduced in commit
905f0ff393629ddb4d70e3dc221b016128c47415 to switch to
kgio for timed, synchronous waiting.
|
|
Since kgio_wait_*able in kgio 2.5 takes an optional timeout
argument, we no longer have to load the extra "io/wait" module.
This saves us a small amount of some memory and also removes the
extra ioctl(FIONREAD) syscall IO#wait enforces.
Like IO#wait in Ruby 1.9.3dev, kgio_wait_readable may use
ppoll() to wait on high-numbered file descriptors as efficiently
as it waits on low-numbered descriptors.
|
|
No point in keeping it around to eat memory.
|
|
We can't wait for longer than 68 years.
|
|
Rainbows! now scales to more than 1024 worker processes without
special privileges. To enable this, Rainbows! now depends on
Unicorn 4.x and thus raindrops[1].
client_max_header_size directive is added to limit per-client
memory usage in headers.
An experimental StreamResponseEpoll concurrency option now
exists to buffer outgoing responses without any thread-safe
dependencies. Unlike the rest of Rainbows! which works fine
without nginx, this concurrency option is /only/ supported
behind nginx, even more strongly so than Unicorn itself.
non-nginx LAN clients are NOT supported for this. This relies
on the sleepy_penguin[2] RubyGem (and Linux).
There are some minor bug fixes and cleanups all around. See
"git log v3.4.0.." for details.
[1] http://raindrops.bogomips.org/
[2] http://bogomips.org/sleepy_penguin/
|
|
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.
|