| Date | Commit message (Collapse) |
|---|
|
|
|
Rack::Utils::HTTP_STATUS_CODES does not define all status codes
that are assigned by IANA nor does it handle
experimental/unknown/ad-hoc status codes. So fall back to
blindly accepting the status code as given by the application
and hope it works.
|
|
|
|
"/dev/null" must be opened in binary mode for Rack-compliance.
Additionally, avoid '' to create an empty string and use
Unicorn::Z instead.
|
|
With the 1.9.2preview1 release (and presumably 1.9.1 p243), the
Ruby core team has decided that bending over backwards to
support crippled operating/file systems was necessary and that
files must be closed before unlinking.
Regardless, this is more efficient than using Tempfile because:
1) no delegation is necessary, this is a real File object
2) no mkdir is necessary for locking, we can trust O_EXCL
to work properly without unnecessary FS activity
3) no finalizer is needed to unlink the file, we unlink
it as soon as possible after creation.
(cherry picked from commit 344b85ff28e160daa6563ab7c80b733abdeb874a)
Conflicts:
lib/unicorn.rb
lib/unicorn/app/exec_cgi.rb
lib/unicorn/tee_input.rb
|
|
|
|
FD_CLOEXEC is not guaranteed to be inherited by the accept()-ed
descriptors even if the listener socket has this set. This can
be a problem with applications that fork+exec long running
background processes.
Thanks to Paul Sponagl for helping me find this.
|
|
(cherry picked from commit ec70433f84664af0dff1336845ddd51f50a714a3)
|
|
Now that we support tunnelling arbitrary protocols over HTTP as
well as "100 Continue" responses, TCP_NODELAY actually becomes
useful to us. TCP_NODELAY is actually reasonably portable
nowadays; even.
While we're adding non-portable options, TCP_CORK/TCP_NOPUSH can
be enabled, too. Unlike some other servers, these can't be
disabled explicitly/intelligently to force a flush, however.
However, these may still improve performance with "normal" HTTP
applications (Mongrel has always had TCP_CORK enabled in Linux).
While we're adding OS-specific features, we might as well
support TCP_DEFER_ACCEPT in Linux and FreeBSD the "httpready"
accept filter to prevent abuse.
These options can all be enabled on a per-listener basis.
(cherry picked from commit 563d03f649ef31d2aec3505cbbed1e015493b8fc)
|
|
This number of retries and delay taken directly from nginx
(cherry picked from commit d247b5d95a3ad2de65cc909db21fdfbc6194b4c9)
|
|
This allows another process to take our listeners
sooner rather than later.
(cherry picked from commit 8c2040127770e40e344a927ddc187bf801073e33)
|
|
|
|
Bah, it's so much busy work to deal with this as configuration
option. Maybe I should say we allow any logger the user wants,
as long as it's $stderr :P
|
|
Make us look even better in "Hello World" benchmarks!
Passing a third parameter to avoid the constant lookup
for the HttpRequest object doesn't seem to have a
measurable effect.
|
|
This should be faster/cheaper than using an instance variable
since it's accessed in a critical code path. Unicorn was never
designed to be reentrant or thread-safe at all, either.
|
|
This makes SIGHUP handling more consistent across different
configurations, and allows togging preload_app to take effect
when SIGHUP is issued.
|
|
There is a potential race condition in closing the tempfile
immediately after SIGKILL-ing the child. So instead just
close it when we reap the dead child.
Some some versions of Ruby may also not like having the
WORKERS hash being changed while it is iterating through
each_pair, so dup the hash to be on the safe side (should
be cheap, since it's not a deep copy) since kill_worker()
can modify the WORKERS hash.
This is somewhat of a shotgun fix as I can't reproduce the
problem consistently, but oh well.
|
|
|
|
This should prevent Rack from being required too early
on so "-I" being passed through the unicorn command-line
can modify $LOAD_PATH for Rack
|
|
No point in refreshing the list of gems unless the app
can actually be reloaded.
|
|
On application reloads, Gems installed by the Ruby instance may
be different than when Unicorn started. So when preload_app is
false, HUP-ing Unicorn will always refresh the list of Gems
before loading the application code.
|
|
* commit 'v0.7.1':
unicorn 0.7.1
Conflicts:
lib/unicorn/const.rb
|
|
|
|
Rack::Lint says they just have to work when to_i is
called on the status, so that's what we'll do.
|
|
2 seconds is still prone to race conditions under high load.
We're intentionally less accurate than we could be in order to
reduce syscall and method dispatch overhead.
|
|
|
|
Ensure we preserve both internal and external encodings
when reopening logs.
|
|
|
|
This makes it easier to use "killall -$SIGNAL unicorn"
without having to lookup the correct PID.
|
|
Timeouts of less than 2 seconds are unsafe due to the lack of
subsecond resolution in most POSIX filesystems. This is the
trade-off for using a low-complexity solution for timeouts.
Since this type of timeout is a last resort; 2 seconds is not
entirely unreasonable IMNSHO. Additionally, timing out too
aggressively can put us in a fork loop and slow down the system.
Of course, the default is 60 seconds and most people do not
bother to change it.
|
|
"out" was an invalid variable in that context...
|
|
Don't allow newly created IO objects to get GC'ed and
subsequently close(2)-ed. We're not reopening the
{$std,STD}{in,out,err} variables since those can't be
trusted to have fileno 1, 2 and 3 respectively.
|
|
Unicorn proper no longer needs these constants,
so don't bother with them.
|
|
Rack::Lint says they just have to work when to_i is
called on the status, so that's what we'll do.
|
|
Preventing needless duplication since Rack already has these
codes for us. Also, put the status codes in HttpResponse since
nothing else needs (or should need) them.
|
|
There may be other logs opened if preload_app is true
besides stderr/stdout paths. So err on the safe side
and reopen everything.
|
|
If we're using middleware that pushes the body into an
array, bad things will happen if we're clobbering the
string for each iteration of body#each.
|
|
Give this a more palatable name and unfreeze it,
allowing users to modify it more easily.
|
|
This used to happen on machines that were coming out of
suspend/hibernation.
|
|
2 seconds is still prone to race conditions under high load.
We're intentionally less accurate than we could be in order to
reduce syscall and method dispatch overhead.
|
|
This reduces garbage generation to improve performance. Rack
1.0 allows InputWrapper to read with an explicit buffer.
|
|
This allows alternative I/O implementations to be easier
to use with Unicorn...
|
|
|
|
Ensure we preserve both internal and external encodings
when reopening logs.
|
|
These potentially leaves an open file handle around until the
next request hits the process, but this makes the common case
faster.
|
|
|
|
First, reduce no-op fchmod syscalls under heavy traffic.
gettimeofday(2) is a cheaper syscall than fchmod(2). Since
ctime resolution is only in seconds on most filesystems (and
Ruby can only get to seconds AFAIK), we can avoid fchmod(2)
happening within the same second. This allows us to cheat on
synthetic benchmarks where performance is measured in
requests-per-second and not seconds-per-request :)
Secondly, cleanup the acceptor loop and avoid nested
begins/loops as much as possible. If we got ECONNABORTED, then
there's no way the client variable would've been set correctly,
either. If there was something there, then it is at the mercy
of the garbage collector because a method can't both return a
value and raise an exception.
|
|
Use SIGQUIT if you're going to be nice and do graceful
shutdowns. Sometimes people run real applications on this
server and SIGINT/SIGTERM get lost/trapped when Object is
rescued and that is not good. Also make sure we break out of
the loop properly when the master is dead.
Testcases added for both SIGINT and dead master handling.
|
|
If our response succeeds, we've already closed the socket.
Otherwise, we would've raised an exception at some point hit one
of the rescue clauses.
|
|
This makes it easier to use "killall -$SIGNAL unicorn"
without having to lookup the correct PID.
|