| Date | Commit message (Collapse) |
|---|
|
Array#[] lookups are slightly faster under both rbx and 1.9,
and easier to read.
|
|
Oops, looks like 1.9.1 exports the RUBY_ENGINE constant.
|
|
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..)
|
|
|
|
|
|
This will allow us to be working_directory-aware as
far as config.ru goes.
|
|
Some folks can now show off their Rainbows! installation
|
|
Don't try to redirect until we know our FIFO consumers are
ready for us. This only seems to happen with bash and not
ksh...
commit d0a0883eaaeec37800ca5cd07647b7b66a00c453 in Unicorn
|
|
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.
|
|
|
|
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.
|