Date | Commit message (Collapse) |
|
We still use and define Rev internally, but that's
mostly just manual labor of converting stuff over.
|
|
This requires manual verification :<
|
|
We need to be able to set this with keepalive_timeout
simultaneously.
|
|
We need to ensure the first worker has started and is
running before attempting to signal the reload.
|
|
The worker process may fork before the original process
is killed during daemonization.
|
|
Cool.io is the new name for Rev. We'll continue to support Rev
until Cool.io breaks backwards compatibility. Rev may not be
supported if Cool.io is.
|
|
It still burns CPU at the first sign of doing anything
interesting, so stop it. Ruby 1.9 is the future :P
|
|
Unicorn 3.2.1 gives us an improved HttpParser#next? that
preserves state until the next HttpParser#parse call.
|
|
This was causing unrelated requests to get killed every
+timeout+ seconds, instead of only the ones that were
running too long.
Noticed-by: ghazel@gmail.com
ref:
http://mid.gmane.org/AANLkTi=7OhyTwkHsp_rXU7Gp1PokihiQ9bJigpO-BfN6@mail.gmail.com
|
|
We'll be taking advantage of configurable
client_buffer_body_size soon.
|
|
This was completely overlooked for the Rainbows 2.0.x
releases.
|
|
We use real tabs for indenting shell code since it is not Ruby.
|
|
Large uploads behave differently with regard to buffering,
and there were bugs in the way the Rev and Revactor backends
handled uploads.
|
|
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.
|