Date | Commit message (Collapse) |
|
This causes conflicts with ports clients may use in
the ephemeral range since those do not hold FS locks.
This reverts commit e597e594ad88dc02d70f7d3521d0d3bdc23739bb.
Conflicts:
test/test_helper.rb
|
|
Duh...
|
|
Response bodies may capture the block passed to each
and save it for body.close, so don't close the socket
before we have a chance to call body.close
|
|
More config bloat, sadly this is necessary for Rainbows! :<
|
|
Since modern machines have more memory these days and
clients are sending more data, avoiding potentially slow
filesystem operations for larger uploads can be useful
for some applications.
|
|
This has been broken since 2.0.x
Internal cleanups sometimes have unintended consequences :<
|
|
In case a request sends the header and buffer as one packet,
TeeInput relying on accounting info from StreamInput is harmful
as StreamInput will buffer in memory outside of TeeInput's
control.
This bug is triggered by calling env["rack.input"].size or
env["rack.input"].rewind before to read.
|
|
This will help ensure we trap our own errors properly
in the future.
|
|
oops :x
|
|
This allows users to override the current Rack spec and disable
the rewindable input requirement. This can allow applications
to use less I/O to minimize the performance impact when
processing uploads.
|
|
We need to ensure the old worker is reaped before sending
new requests intended for the new worker.
|
|
If a configuration directive is set at startup and later
unset, it correctly restores the original default value
as if it had never been set in the first place.
This applies to the majority of the configuration values with
a few exceptions:
* This only applies to stderr_path and stdout_path when
daemonized (the usual case, they'll be redirected to
"/dev/null"). When NOT daemonized, we cannot easily redirect
back to the original stdout/stderr destinations.
* Unsetting working_directory does not restore the
original working directory where Unicorn was started.
As far as we can tell unsetting this after setting it is
rarely desirable and greatly increases the probability of
user error.
|
|
This may be useful for some apps that wish to drain the body
before acquiring an app-wide lock. Maybe it's more useful
with Rainbows!...
|
|
Automation is nice, the makefile needs some cleanup
|
|
We'll be using more of Isolate in development.
|
|
While we've always unlinked dead sockets from nuked/leftover
processes, blindly unlinking them can cause unnecessary failures
when an active process is already listening on them. We now
make a simple connect(2) check to ensure the socket is not in
use before unlinking it.
Thanks to Jordan Ritter for the detailed bug report leading to
this fix.
ref: http://mid.gmane.org/8D95A44B-A098-43BE-B532-7D74BD957F31@darkridge.com
|
|
Rails 3 is out, and requires no code changes on our end to work
(as far as our tests show :)
|
|
These nasty hacks were breaking Rubinius compatibility.
This can be further cleaned up, too.
|
|
No code changes needed, thankfully.
|
|
Something is wrong if workers exit with a non-zero status,
so we'll increase the log level to help prevent people
from missing it.
|
|
In addition to SIGHUP, it should be possible to gradually bring
workers back up (to avoid overloading the machine) when rolling
back upgrades after SIGWINCH.
Noticed-by: Lawrence Pit
ref: http://mid.gmane.org/4C3F8C9F.2090903@gmail.com
|
|
As described in our SIGNALS documentation, sending SIGHUP to the
old master (to respawn SIGWINCH-ed children) while the new
master (spawned from SIGUSR2) is active is useful for backing
out of an upgrade before sending SIGQUIT to the new master.
Unfortunately, the SIGHUP signal to the old master will cause
the ".oldbin" pid file to be reset to the non-".oldbin" version
and thus attempt to clobber the pid file in use by the
to-be-terminated new master process.
Thanks to the previous commit to prevent redaemonization in the
new master, the old master can reliably detect if the new master
is active while it is reloading the config file.
Thanks to Lawrence Pit for discovering this bug.
ref: http://mid.gmane.org/4C3BEACF.7040301@gmail.com
|
|
test-lib handles variables named "*socket" (and "*fifo")
differently than ordinary variables.
|
|
Our fugly code can't handle embedded command-line options in
config.ru when using Rubinius yet. So add some related tests
to the ones marked RBX_SKIP that don't rely on embedded
command-line options.
|
|
While log reopening worked reliably for newly-created File
objects in the unit tests, the $stderr and $stdout handles that
get redirected did not get reopened reliably under Rubinius.
We work around this by relying on Rubinius internals and
directly setting the @path instance variable. This is harmless
for MRI and should be harmless for other any other Ruby
implementations we'll eventually support.
ref: http://github.com/evanphx/rubinius/issues/360
|
|
Ruby 1.9.2 no longer adds the current directory to $LOAD_PATH
automatically.
|
|
|
|
|
|
We share the same array from the original bin/* down
into the Configurator.
|
|
This was commit abc207b2918606867094f2820bab58223e99aac4 from
rainbows.git
|
|
|
|
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...
|
|
eval("...", TOPLEVEL_BINDING) is broken for us in Rubinius
(And our code is extremely nasty as well :x)
ref: http://github.com/evanphx/rubinius/issues/357
|
|
|
|
Rails 3 will automatically load it for us.
|
|
more tests may use it
|
|
|
|
Since we added support for the "working_directory" parameter, it
often became unclear where/when certain paths would be bound.
There are some extremely nasty dependencies and ordering issues
when doing this. It's all pretty fragile, but works for now
and we even have a full integration test to keep it working.
I plan on cleaning this up 2.x.x to be less offensive to look
at (Rainbows! and Zbatery are a bit tied to this at the moment).
Thanks to Pierre Baillet for reporting this.
ref: http://mid.gmane.org/AANLkTimKb7JARr_69nfVrJLvMZH3Gvs1o_KwZFLKfuxy@mail.gmail.com
|
|
It's a good idea to use a caching http_proxy to save bandwidth
when isolating gems for different Ruby versions.
|
|
In case we have weird Rails 3 users who choose to ignore
config.ru, we'll be ready.
|
|
We'll be adding more Rails 3 tests..
|
|
Oops, but unicorn_rails appears to work well here
|
|
In parallel with other of Rubies, of course. We need to rely on
RUBY_ENGINE since RUBY_VERSION is 1.8.7 and that conflicts with
the most popular MRI version.
Since Rubinius doesn't support some command-line options, we
still need to rely on MRI for a few things. Also fixing an
embarrassing UUoC in the process.
|
|
should be safe enough...
|
|
We'll be switching to Isolate and shell-based tests
since the old test/unit-based Rails test was basically
a shell script written in Ruby.
|
|
This should make it easier to reuse code in derivative
servers like Rainbows! and Zbatery. Unfortunately, we
can't depend on Rack::Builder/Rack::Server yet since
Rack 1.1 just got them and notable frameworks (like
Rails 2.3.x) do not fully work with Rack 1.1 yet).
This also fixes subtle issue with config.ru files that could
have variables that conflict with the Unicorn-specific
namespace (this bug still affects "unicorn_rails", which
could use some reworking as well).
|
|
If preload_app is true and Unicorn is HUP-ed with a bad
config.ru, then it would be possible to have Unicorn in a bad
state and constantly throw 500 errors.
We now detect syntax and load errors since they're likely to
appear in modified Rackup files, and will restore the original
app if reloading failed.
|
|
|
|
|