Date | Commit message (Collapse) |
|
On FreeBSD 9.0, "wc -l" emits leading whitespace, so
filter it through tr -d '[:space:]' to eliminate it.
|
|
On FreeBSD 9.0, "wc -c" emits leading whitespace, so
filter it through tr -d '[:space:]' to eliminate it.
|
|
"date +%s" is not in POSIX (it is in GNU, and at least FreeBSD
9.0, possibly earlier). The Ruby equivalent should be
sufficiently portable between different Ruby versions.
This change was automated via:
perl -i -p -e 's/date \+%s/unix_time/' t/*.sh
|
|
The latest Linux series is now 3.x, not 2.6.x
|
|
This makes things easier to maintain as we add more concurrency
options.
|
|
This allows using IO::Splice.copy_stream from the "io_splice"
RubyGem on recent Linux systems. This also allows users to
disable copy_stream usage entirely and use traditional
response_body.each calls which are compatible with all Rack
servers (to workaround bugs in IO.copy_stream under 1.9.2-p180).
|
|
We need to be able to set this with keepalive_timeout
simultaneously.
|
|
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.
|
|
We need to ensure the old worker is really dead before sending
requests after reloading.
|
|
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 testers (like myself) use http_proxy when isolating
gems to avoid wasting bandwidth, but we don't proxy requests
to localhost.
|
|
It hasn't been used since the first month of development
when we started using FIFOs
|
|
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.
|
|
non-random_blob arguments weren't being taken into account
correctly :x
|
|
|
|
Since Rainbows! is supported when exposed directly to the
Internet, administrators may want to limit the amount of data a
user may upload in a single request body to prevent a
denial-of-service via disk space exhaustion.
This amount may be specified in bytes, the default limit being
1024*1024 bytes (1 megabyte). To override this default, a user
may specify `client_max_body_size' in the Rainbows! block
of their server config file:
Rainbows! do
client_max_body_size 10 * 1024 * 1024
end
Clients that exceed the limit will get a "413 Request Entity Too
Large" response if the request body is too large and the
connection will close.
For chunked requests, we have no choice but to interrupt during
the client upload since we have no prior knowledge of the
request body size.
|
|
enabling ready_pipe in Unicorn 0.96.0 breaks this.
|
|
too dangerous with the ready_pipe feature in Unicorn 0.96+
|
|
If we logged "ERROR", we should know about it.
|
|
And change the default to 2 seconds, most clients can
render the page and load all URLs within 2 seconds.
|
|
Avoid the chances of misfiring when waiting on the master
process to start in case something bad happens or we're
sharing the FIFO for other purposes.
|
|
sha1sum(1) is only common GNU systems, and it may be installed
as gsha1sum on *BSDs. We'll also try using the openssl sha1
implementation, too. And finally, we'll provide our own Ruby
sha1sum.rb implementation as a last resort.
We go to great lengths to avoid our own Ruby version because we
want to avoid putting too much trust in ourselves, our Ruby
skills, and even the Ruby implementations. This is especially
with regard to our knowledge and correct usage of Ruby 1.9
encoding support. It would actually be *easier* to only use
sha1sum.rb and call it a day. We just choose to support
SHA1 implementations provided by third parties if possible.
Performance is not a factor since sha1sum.rb performance is very
close to the C implementations.
|
|
|
|
|
|
This will make it easier to enable and manage tests for new
concurrency models.
|
|
Everything passes, and "set -e" prevents us from
making any stupid mistakes...
|
|
Instead of sleeping and waiting for a PID file to appear,
just use a named-pipe and block on it in the test scripts
since we know Unicorn won't attempt to fork until sockets
are already bound.
|
|
It's more common form for externally-visible/modifiable
variables in Makefiles and shell scripts.
|
|
Don't try to clobber FIFOs at startup since sometimes traps may
not fire. And while we're at it, avoid trying to unlink them
twice.
|
|
Instead of using completely random names, we'll use
predictable ones since we already depend on them for
exit codes and such. This drops our ability to run
the same test for the same version of Ruby in the
same working tree, but that's an unlikely scenario.
While we're at it, avoid remove tempfiles if a test
failed. This should make debugging easier.
|
|
If we're going to name a variable "fifo", it'll be for
descriptive reasons...
|
|
We now check for SIGKILL, too
|
|
|
|
|
|
We'll spit out a proper warning later anyways...
|
|
|
|
|
|
At least these tests all run with dash now, but ksh93
or bash is still recommended for pipefail
|
|
This makes it easier to write/share code for multi-model tests.
|
|
Makes it easier to track down empty files this way
|
|
There is no TeeInput (streaming request body) support, yet,
as that does not seem fun nor easy to do (or even possible
without using Threads or Fibers or something to save/restore
the stack...)
|
|
pipefail is extremely useful for detecting bad exits _anywhere_
in pipelines, not just the last command. Combined with
"set -e", pipefail leads to very unforgiving scripts that
bail out at the first sign of error, exactly what we want
in tests.
|
|
Useful for prefixing individual lines of a temporary
file while catting it to stdout. This helps make tests
easier to write and test.
|
|
Since we rely heavily on temporary files in tests, make
sure management of them is easy and reliable.
|
|
Everything is logged in git anyways and it'll be easier to
hand off to somebody else.
|
|
I'd rather write shell scripts in shell than shell scripts in
Ruby like was done with Unicorn. We're a *nix-only project so
we'll embrace *nix tools to their fullest extent and as a
pleasant side-effect these test cases are immune to internal API
changes.
|