| Date | Commit message (Collapse) |
|---|
|
Due to the synchronous nature of Revactor, we can
be certain sendfile won't overstep the userspace
output buffering done by Rev.
|
|
Our test suite doesn't include facilities for dealing
with temporary directories, yet.
|
|
We may want to try some external libraries for some tests
via RUBYLIB/RUBYOPT while doing development.
|
|
Proxying regular Ruby IO objects while Revactor is in use is
highly suboptimal, so proxy it with an Actor-aware wrapper for
better scheduling.
|
|
Since TCP sockets stream, HTTP requests do not come in at
well-defined boundaries and it's possible for pipelined requests
to come in in a staggered form. We need to ensure our
receive_data callback doesn't fire any actions at all while
responding with a deferrable @body.
We still need to be careful about buffering, since EM does not
appear to allow temporarily disabling read events (without
pausing writes), so we shutdown the read end of the socket
if it reaches a maximum header size limit.
|
|
It hits 100% CPU usage and Rev's 1.8 support when mixed
with threads is currently suboptimal. Unfortunately
our tests can not check for 100% CPU usage, so I had to
*gasp* confirm it by actually starting an app :x
This appears to be a fixable bug in Rev, however, and
we'll try to fix it as soon as we have time.
|
|
They were taking long enough to be annoying :<
|
|
HTTP/1.1 and HTTP/1.0 code paths may vary significantly from the
(highly uncommon) HTTP/0.9 ones in our concurrency models,
so add extra tests for those.
|
|
EM::FileStreamer writes may be intermingled with the headers
in the subsequent response if we enable processing of the
second pipelined response right away, so wait until the
first response is complete before hitting the second one.
This also avoids potential deep stack recursion in the unlikely
case where too many requests are pipelined.
|
|
With sendfile enabled, we must avoid writing headers (or normal,
non-file responses) while a file is deferred for sending. This
means we must disable processing of new requests while a file
is deferred for sending and use the on_write_complete callback
less aggressively.
|
|
Those are entirely single-threaded during the application
dispatch phase.
|
|
While gawk can handle binary data, other awks cannot, so
use tr(1) to filter out non-printable characters from the
WebSocket message. We need to send a bigger message, too,
since tr(1) output is buffered and there's no portable way
to unbuffer it :<
|
|
|
|
The FileStreamer class of EventMachine (and by extension
NeverBlock) unfortunately doesn't handle this. It's possible
to do with Revactor (since it uses Rev under the covers),
but we'll support what we can easily for now.
|
|
We need to remember to close response bodies even if
a client aborts the connection, since body.close can
trigger interesting things like logging and such...
|
|
Middlewares like Clogger may wrap Rack::File responses
with another body that responds to to_path and still
rely on #close to trigger an action (writing out the log
file).
|
|
Some middlewares such as Clogger rely on wrapping the body
having the close method called on it for logging.
|
|
This makes it easier to write proxies for slow clients that
benefit from keep-alive. We also need to be careful about
non-HTTP/1.1 connections that can't do keepalive, now.
|
|
If a response proxying a pipe (or socket) includes a
Content-Length, do not attempt to outsmart the application
and just use the given Content-Length.
This helps avoid exposing applications to weird internals such
as env["rainbows.autochunk"] and X-Rainbows-* response headers.
|
|
Using EM.enable_proxy with EM.attach seems to cause
EM::Connection#receive_data callbacks to be fired before the
proxy has a chance to act, leading the first few chunks of data
being lost in the default receive_data handler. Instead
just rely on EM.watch like the chunked pipe.
|
|
This avoids costant resolution problems on client EOF
during input processing.
|
|
|
|
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).
|
|
|
|
|
|
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...
|
|
We shouldn't ever spew errors to the stderr/logger
on client disconnects (ECONNRESET/EPIPE/etc...).
|
|
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.
|
|
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.
|
|
|
|
|
|
We only read from the IO pipe and never write to it
|
|
They're ugly and potentially non-portable to other servers.
They also make Unicorn + Rubinius unhappy, which makes us
unhappy as well.
|
|
Everything should be working under Ruby 1.9.2(-preview3) now.
|
|
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..)
|
|
|
|
|
|
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
|
|
|
|
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.
|
|
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...
|
|
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
|