| Date | Commit message (Collapse) |
|---|
|
All synchronous models have this fixed in unicorn 3.0.1,
so only Rev and EventMachine-based concurrency models
require code changes.
|
|
Unicorn 3.0.0 is final and released, so we will use it in our
tests
|
|
To avoid denial-of-service attacks, the wrappers need to
intercept requests *before* they hit the memory allocator, so we
need to reimplement the read(all) and gets cases to use
smaller buffers whenever the application does not specify one.
|
|
Kgio 2.0.0 has a superior API and less likely to conflict or
blow up with other applications. Unicorn 3.x requires Kgio 2.x,
too.
|
|
It allows disabling rewindable input and contains
simpler code for upload processing.
|
|
We need to ensure the old worker is really dead before sending
requests after reloading.
|
|
On busy machines, old workers may not shutdown quickly
enough and may still be processing requests.
|
|
For consistency, changed settings are reset back to
their default values if they are removed or commented
out from the config file.
|
|
Unicorn 2.0.0 has CPU wakeup reductions.
|
|
Applications may use wait_readable-aware methods directly
to work with Rainbows!
|
|
We get basic internal API changes from Unicorn,
code simplifications coming next.
|
|
It removes the burden of byte slicing and setting file
descriptor flags. In some cases, we can remove unnecessary
peeraddr calls, too.
|
|
Unicorn 1.1.3 fixes potential race conditions during
SIGUSR1 log reopening.
|
|
Although this behavior is mentioned on the documentation,
this was broken under EventMachine, Rev*, and Revactor.
Furthermore, we set the "Connection: close" header to allow the
client to optimize is handling of non-keepalive connections.
|
|
Rack::Lint uses String#inspect to generate assertion messages
whether or not the assertions are triggered at all.
Unfortunately String#inspect is hilariously slow under 1.9.2
when dealing with odd characters and large strings.
The performance difference is huge:
before: 1m4.386s
after: 0m3.877s
We already have Rack::Lint enabled everywhere else, so removing
this where performance matters most shouldn't hurt us.
|
|
This allows for per-dispatch timeouts similar to (but not exactly)
the way Mongrel (1.1.x) implemented them with threads.
|
|
First off we use an FD_MAP to avoid creating redundant IO
objects which map to the same FD. When that doesn't work, we'll
fall back to trapping Errno::EBADF and IOError where
appropriate.
|
|
Not sure what possessed me to clobber the original
variable set in the parent, but the initial time
for the subshell could be set too late in relation
to the actual server time. So we need to stash the
original time before any HTTP requests were made.
|
|
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
|