| Date | Commit message (Collapse) |
|---|
|
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.
|
|
|
|
Apparently this document was completely forgotten over the
course of development and never properly put on the website.
The test suite is one of my favorite parts of Rainbows! and
allows us to test the server as real clients would hit it.
|
|
Since the docs for this project are hosted on Rubyforge.org
(currently Apache), it can't use the nginx "gzip_static on"
configuration I normally use on on *.bogomips.org.
I never used the irb/sh wrappers in local.mk, either, and
the isolate bits have all been moved inside t/
|
|
It was missing dependencies on the first run
|
|
We don't need tmp/ in our top level directory
|
|
Sinatra 0.9.4 does not appear to be compatible with
Ruby 1.9.2...
|
|
It makes tests run significantly faster on a beefy box.
|
|
Now that 1.9.2 preview3 is available and usable, it'll
be added to the list of Rubies we run and officially
support.
|
|
Yes there's a reason for everything we do :>
|
|
Some testers (like myself) use http_proxy when isolating
gems to avoid wasting bandwidth, but we don't proxy requests
to localhost.
|
|
It's useful given all the Gems we support but don't have hard
installation dependencies on.
|
|
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.
|
|
It hasn't been used since the first month of development
when we started using FIFOs
|
|
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.
|
|
|
|
I still have a hard time keeping track of what's capable of
what.
|
|
it's hard to make this test reliable, but try to
add a small fudge factor based on the MRI default
GC malloc limit.
|
|
|
|
This should be logical, since we keep the connection alive
when writing in our writer threads.
|
|
|
|
|
|
|
|
no major internal changes until 2.0.0+
|
|
It's not worth the trouble and testability since having
a single thread tends to bottleneck if there's a bad
client.
|
|
This allows it to be a symlink to /dev/shm or similar
|
|
curl < 7.18.0 did not check for errors when doing chunked
uploads. Unfortunately some distros are slow moving and
bundle ancient versions of curl.
|
|
|
|
since we don't set maximum time boundaries, just rely on
the logs to properly log the dead processes.
|
|
since we've already waited for time to elapse, there's no
point in watching the upper limit here
|
|
This test can cause a lot of I/O, especially when
run in parallel. Just rely on the fixed rsha1 code
to compute the SHA1 of the response.
|
|
non-random_blob arguments weren't being taken into account
correctly :x
|
|
slow test runners can buffer us and bloat memory usage
unpredictably when tests are run under load
|
|
On busy sytems, this timing-sensitive test is likely to fail,
so give it some extra slack
|
|
|
|
Idle threads are cheap enough and having responses
queued up with a single slow client on a large response
is bad.
|
|
This is based on an idea I originally had for Unicorn but never
implemented in Unicorn since the benefits were unproven and the
risks were too high.
|
|
It'll be useful later on for a variety of things!
|
|
|
|
|
|
|
|
Mostly internal cleanups and small improvements.
The only backwards incompatible change was the addition of the
"client_max_body_size" parameter to limit upload sizes to
prevent DoS. This defaults to one megabyte (same as nginx), so
any apps relying on the limit-less behavior of previous will
have to configure this in the Unicorn/Rainbows! config file:
Rainbows! do
# nil for unlimited, or any number in bytes
client_max_body_size nil
end
The ThreadSpawn and ThreadPool models are now optimized for serving
large static files under Ruby 1.9 using IO.copy_stream[1].
The EventMachine model has always had optimized static file
serving (using EM::Connection#stream_file_data[2]).
The EventMachine model (finally) gets conditionally deferred app
dispatch in a separate thread, as described by Ezra Zygmuntowicz
for Merb, Ebb and Thin[3].
[1] - http://euruko2008.csrug.cz/system/assets/documents/0000/0007/tanaka-IOcopy_stream-euruko2008.pdf
[2] - http://eventmachine.rubyforge.org/EventMachine/Connection.html#M000312
[3] - http://brainspl.at/articles/2008/04/18/deferred-requests-with-merb-ebb-and-thin
|
|
IO#readpartial on zero bytes will always return an empty
string, so ensure the emulator for Revactor does that as
well.
|
|
|
|
Even if it's just an empty file for now, it's critical in
case we ever add any code that returns user-visible strings
since Rack::Lint (and mere sanity) require binary encoding
for "rack.input".
|
|
We expect no API changes in Unicorn for a while
|
|
|
|
Paragraph ordering matters psychologically.
|
|
Since deferred requests run in a separate thread, this affects
the root (non-deferred) thread as well since it may share
data with other threads.
|