Date | Commit message (Collapse) |
|
For consistency with rev_write_response (and the existing
"write_response").
|
|
Cramp needs to override our normal header sending for
(old) WebSockets connections.
|
|
Cramp monkey patches Rainbows internals for WebSockets
support and we forgot about it. Add a new integration
test to ensure this continues to work in the future
(and force us to update the test for newer Cramp).
|
|
Unicorn 1.1.0 lets us change this default, and we need it higher
to avoid wasting workers against stupidly (or maliciously) slow
clients.
|
|
Other concurrency models will eventually be able to use it, too.
|
|
rb_str_slice_bang() allocates a new string internally and calls
rb_str_aref_m() AND rb_str_aset_m(), too. String#[] just
calls rb_str_aref_m() directly, so it's a much quicker code
path. Also, "[]" methods dispatch faster under 1.9, too.
|
|
Fortunately this only affects the hardly-used FiberSpawn and
FiberPool concurrency models, and also unreleased revisions of
Rev. 1.9 encoding is tricky to handle right when doing I/O in
Ruby...
|
|
non-blocking write() may cause kernel buffers to be allocated
behind the scenes, so retry the write() even if it's short
because it may succeed the next time around.
|
|
We shouldn't ever spew errors to the stderr/logger
on client disconnects (ECONNRESET/EPIPE/etc...).
|
|
There's no need to ever change the underlying offset of a file
descriptor when using sendfile(), so don't. This allows us to
avoid contention in the kernel/filesystem and eventually reuse
the same filesystem file descriptor for serving multiple
requests.
|
|
We need to load sendfile-using parts after the
"sendfile" library is loaded.
|
|
This hopefully allows the "sendfile" gem to be required
anywhere in the Rainbows!/Unicorn config file, and not
have to be required via RUBYOPT or the '-r' command-line
switch.
We also modularize HttpResponse and avoids singleton methods
in the response path. This (hopefully) makes it easier for
individual concurrency models to share code and override
individual methods.
|
|
Avoid confusing people with an overloaded method name
|
|
While we're at it, fix a comment, too.
|
|
We may use a blocking accept() loop if there is
only a single listener. In that case threads may
not be able to exit if a SIGQUIT is received, so
force them to run when joining.
|
|
This should improve performance for static file responses.
|
|
slowly cleaning up the generated RDoc
|
|
|
|
This still needs work and lots of cleanup, but the basics are
there. The sendfile 1.0.0 RubyGem is now safe to use under MRI
1.8, and is superior to current (1.9.2-preview3) versions of
IO.copy_stream for static files in that it supports more
platforms and doesn't truncate large files on 32-bit platforms.
|
|
This fleshes out Rainbows::Fiber::IO with a few
more methods for people using it.
|
|
|
|
|
|
|
|
No point in using a class here, there's no object
|
|
|
|
No point in documenting our internals and overwhelming
users.
|
|
Rack::Contrib::Sendfile moved into Rack in December 2009.
|
|
Make it easier to link to the Rainbows! configuration
documentation without anchors. This also reduces the
amount of code we spew into Unicorn::Configurator.
|
|
|
|
We can't use it effectively in Rubinius yet, and it's
broken due to the issue described in:
http://github.com/evanphx/rubinius/issues/379
|
|
There's no need to #dup the middleware object, just use
a custom Rainbows::DevFdResponse::Body object.
|
|
|
|
I was originally experimenting with setsockopt to increase the
kernel buffer sizes in a loop, but the benefits were negligible
at best.
|
|
For small responses that can fit inside a kernel socket
buffer, copying that data into an IO::Buffer object is
a waste of precious memory bandwidth.
|
|
This gives a tiny performance improvement to the FiberSpawn and
FiberPool concurrency models.
|
|
Not that many people will actually call Rainbows.sleep
outside of tests...
|
|
HeaderHash objects can only be used as headers without
violating Rack::Lint in Rack 1.1.0 or later.
|
|
Array#[] lookups are slightly faster under both rbx and 1.9,
and easier to read.
|
|
Rubinius still has a few issues that prevent 100% support,
but it basically works if log rotation or USR2 upgrades aren't
required. Tickets for all known issues for Rubinius have
been filed on the project's issue tracker.
* rbx does not support -i/-p yet, so rely on MRI for that
* "io/nonblock" is missing
* avoiding any optional Gems for now (EM, Rev, etc..)
|
|
Some folks can now show off their Rainbows! installation
|
|
duh!
|
|
Since EventMachine and Rev shared the same logic for optimizing
and avoiding extra file opens for IO/File-ish response bodies,
so centralize that.
For Ruby 1.9 users, we've also enabled this logic so ThreadPool,
ThreadSpawn, WriterThreadPool, and WriterThreadSpawn can take
advantage of Rainbows::DevFdResponse-generated bodies while
proxying sockets.
|
|
This release fixes corrupted large response bodies for Ruby 1.8
users with the WriterThreadSpawn and WriterThreadPool models
introduced in 0.93.0. This bug did not affect Ruby 1.9 users
nor the users of any older concurrency models.
There is also a strange new Rainbows::Sendfile middleware. It
is used to negate the effect of Rack::Contrib::Sendfile, if that
makes sense. See the RDoc or
http://rainbows.rubyforge.org/Rainbows/Sendfile.html for all the
gory details.
Finally, the RDoc for our test suite is on the website:
http://rainbows.rubyforge.org/Test_Suite.html
I wrote this document back when the project started but
completely forgot to tell RDoc about it. Personally, this
test suite is one of my favorite parts of the project.
|
|
|
|
This lets most concurrency models understand and process
X-Sendfile efficiently with IO.copy_stream under Ruby 1.9.
EventMachine can take advantage of this middleware under
both Ruby 1.8 and Ruby 1.9.
|
|
While these models are designed to work with IO.copy_stream
under Ruby 1.9, it should be possible to run them under Ruby
1.8 without returning corrupt responses. The large file
response test is beefed up to compare SHA1 checksums of
the served file, not just sizes.
|
|
In our race to have more concurrency options than real sites
using this server, we've added two new and fully supported
concurrency models: WriterThreadSpawn and WriterThreadPool
They're both designed to for serving large static files and work
best with IO.copy_stream (sendfile!) under Ruby 1.9. They may
also be used to dynamically generate long running, streaming
responses after headers are sent (use "proxy_buffering off" with
nginx).
Unlike most concurrency options in Rainbows!, these are designed
to run behind nginx (or haproxy if you don't support POST/PUT
requests) and are vulnerable to slow client denial of service
attacks.
I floated the idea of doing something along these lines back in
the early days of Unicorn, but deemed it too dangerous for some
applications. But nothing is too dangerous for Rainbows! So
here they are now for your experimentation.
|
|
|
|
This should be logical, since we keep the connection alive
when writing in our writer threads.
|
|
|