| Date | Commit message (Collapse) |
|---|
|
Process.spawn is faster under Linux since it may use vfork
to avoid marking pages copy-on-write.
|
|
Getting the logs to show up in order is tricky in a multithreaded
server...
|
|
systemd socket emulation shares FDs across execve, just like
the built-in SIGUSR2 upgrade process in unicorn. Thus it is
easy to support inheriting sockets from systemd.
|
|
We need to wait for the hijacked process to run and write to the
log before we check it. Since we may not have inotify, try to
trigger a sched_yield() syscall instead.
|
|
TCP socket options are now set when inheriting existing sockets from
a parent process. I'm fairly certain all the TCP setsockopt knobs
we use are idempotent and harmless to change.
If anything, the only directive I'd be uncomfortable changing is
shortening the listen(2) (aka :backlog) size, but we've always
changed that anyways since it also applies to UNIX sockets.
Note: removing a configuration knob in a yahns config file can not
reset the value to the OS-provided default setting. Inherited
sockets must use a new setting to override existing ones.
(or the socket needs to be closed and re-created in the process
launcher before yahns inherits it).
Based on unicorn commit 1db9a8243d42cc86d5ca4901bceb305061d0d212
Noticed-by: Christos Trochalakis <yatiohi@ideopolis.gr>
<20150626114129.GA25883@luke.ws.skroutz.gr>
|
|
We want to avoid race conditions if tests become multithreaded
from Kernel#warn internally issuing a second write.
|
|
Middlewares such as Rack::Lock (used by Rails) break badly unless
the response body is closed on hijack, so we will close it to follow
the lead of other popular Rack servers.
While it's unclear if there's anybody using rack.hijack besides
yahns/proxy_pass we'll try to emulate the behavior of other servers
as much as possible.
ref: https://github.com/ngauthier/tubesock/issues/10
While we're at it, use DieIfUsed correctly in test_ssl.rb :x
|
|
We don't require kcar to be installed since most users will never
use the proxy_pass feature, but show an informative error in case
they want to test this functionality.
|
|
Rack::TempfileReaper was added in rack 1.6 to cleanup temporary
files. Make Yahns::TmpIO ducktype-compatible and put it into
env['rack.tempfiles'] array so Rack::TempfileReaper may be used to
free up space used by temporary buffer files.
ref: commit 3bdf5481e49d76b4502c51e5bdd93f68bfd1f0b4 in unicorn
|
|
We do not want rack.hijack users relying on kgio_* methods since
kgio is trying to make itself obsolete (as Ruby itself adopts
kgio features). This is a bit wonky since our common case tries
to minimize object allocation by only using the Kgio::Socket
derived class.
|
|
The entire idea of a one-shot-based design is all the mutual
exclusion is handled by the event dispatch mechanism (epoll or
kqueue) without burdening the user with extra locking. However, the
way the hijack works means we check the Rack env for the
'rack.hijack_io' key which is shared across requests and may
be cleared.
Ideally, this would not be a problem if the Rack dispatch allowed
returning a special value (e.g. ":ignore") instead of the normal
status-headers-body array, much like what the non-standard
"async.callback" API Thin started.
We could also avoid this problem by disallowing our "unhijack-ing"
of the socket but at a significant cost of crippling code
reusability, including that of existing middleware.
Thus, we allocate a new, empty request object here to avoid a TOCTTOU
in the following timeline:
original thread: | another thread
HttpClient#yahns_step |
r = k.app.call(env = @hs.env) # socket hijacked into epoll queue
<thread is scheduled away> | epoll_wait readiness
| ReqRes#yahns_step
| proxy dispatch ...
| proxy_busy_mod_done
************************** DANGER BELOW ********************************
| HttpClient#yahns_step
| # clears env
# sees empty env: |
return :ignore if env.include?('rack.hijack_io') |
In other words, we cannot ever touch the original env seen by the
original thread since it must see the 'rack.hijack_io' value because
both are operating in the same Yahns::HttpClient object. This will
happen regardless of GVL existence.
Avoiding errors like this is absolutely critical to every one-shot
based design.
|
|
Upstreams may shut us down while we're writing a request body,
attempt to forward any responses from the upstream back to the
client which may explain the rejection reason for giant uploads.
|
|
Not all backends are capable of generating chunked responses
(especially not to HTTP/1.0 clients) nor can they generate
the Content-Length (especially when gzipping), so they'll
close the socket to signal EOF instead.
|
|
Since yahns/proxy_pass is not a drop-in replacement, reinstate
the old, synchronous version to avoid breaking existing setups
which require Rack middleware support.
|
|
kgio_writev returns nil on success instead of the number of bytes
written, so we must manually calculate the number of bytes written
intead :x
This is triggerable when sending giant chunked responses.
|
|
On one of my ancient, cache-starved home systems, this tends to
cause pathologically bad performance during some of these tests.
|
|
We cannot pass trailers from upstreams to HTTP/1.0 clients without
fully-buffering the response body AND trailers before forwarding the
response header.
Of course, one of the reasons yahns exists is to support lazy
buffering, so fully-buffering up front is wasteful and hurts
latency. So instead, degrade to 1.0 requests to upstreams for
HTTP/1.0 clients, this should prevent upstreams from sending
trailers in the first place.
HTTP/1.0 clients on Rails apps may suffer, but there probably
are not too many HTTP/1.0 clients out there.
|
|
Rack apps may (through a round-about way) send HTTP trailers
to HTTP/1.1 clients, and we need a way to forward those responses
through without losing the trailers.
|
|
We need to ensure more uncommon cases such as gigantic upstream
headers and truncated upstream responses are handled properly
and predictably.
|
|
Pipelining uploads is rare in practice, but they must behave
properly in case some brave soul wants to start doing it.
|
|
Even if a response is screwed, we need to ensure breakage is
predictable.
|
|
We were incorrectly stashing the return value of detach_rbuf!
into the inter-thread buffer buffer which is bound to the client.
|
|
This allows our reverse proxy to avoid having an innefficient 1:1
relationship between threads and upstream connections, reducing
memory usage when there are many upstream connections (possibly to
multiple backend machines).
|
|
This should make it easier to track state for asynchronous
proxy_pass buffering.
|
|
This will allow us to write arrays for chunked output without
unnecessary data copies.
|
|
This is no longer a part of the "extras" section
|
|
This will rely on rack.hijack in the future to support
asynchronous execution without tying up a thread when waiting
for upstreams. For now, this allows simpler code with fewer
checks and the use of monotonic time on newer versions of Ruby.
|
|
Of course, some users will prefer to bind HTTP application
servers to Unix domain sockets for better isolation and (maybe)
better performance.
|
|
We probably do not want env["rack.input"] to become unusable
upon hijacking. Only drop the internal reference to it so
it can eventually become garbage-collected, but there's no
point in making env["rack.input"] unreadable.
|
|
Oops, this test bug was introduced in:
commit e413325737f23c5ec27a02246f95077bc1fb038d
("acceptor: close inherited-but-unneeded sockets")
|
|
When inheriting sockets from the parent via YAHNS_FD, we must close
sockets ASAP if they are unconfigured in the child. This bug exists
in yahns (and not unicorn) because of the trickier shutdown routine
we do for blocking accept system calls to work reliably with the
threading support in mainline Ruby 2.x. This bug would not exist
in a purely C server using blocking accept, either.
|
|
This module will probably become an official part of yahns
soon, so finally add tests for this module.
|
|
It may be useful for us to track down potential errors in
our code or log when an upstream misbehaves.
|
|
While 1.9.3 support will probably be kept for another year or so,
it's probably not worth supporting non-critical extras/ stuff on
1.9.3.
|
|
Since we only support 1.9.3+, io.stat.size may be simplified
to io.size to reduce allocations of File::Stat objects.
|
|
We'll be writing more SSL-related tests in the future...
|
|
If we're streaming large files and sendfile fails (due to a
client aborting the connection), we need to ensure middleware
proxies are closed to ensure proper logging of a partial request.
This affects users of the "clogger" gem serving static files.
Unfortunately with clogger (or any Rack API-compliant middleware
using "to_path"), we still cannot log the amount of bytes
transferred for a static file.
|
|
We rely on exception-free non-blocking I/O for performance,
so it is easier for us to avoid supporting new features on
old Rubies.
|
|
The current CA model and code quality of OpenSSL have long put me off
from supporting TLS; however but efforts such as "Let's Encrypt"
and the fallout from Heartbleed give me hope for the future.
This implements, as much as possible, a "hands-off" approach to TLS
support via OpenSSL. This implementation allows us to shift
responsibility away from us to users and upstreams (the Ruby 'openssl'
extension maintainers, software packagers, and OpenSSL project itself).
This is also perhaps the easiest way for now for us, while being most
powerful for users. It requires users to configure their own OpenSSL
context object which we'll use as-is.
This context object is used as the :ssl_ctx parameter to the "listen"
directive in the yahns configuration file:
require 'openssl' # we will not do this for the user, even
ctx = OpenSSL::SSL::SSLContext.new
# user must configure ctx here...
listen 443, ssl_ctx: ctx
This way, in case we support GnuTLS or other TLS libraries, there'll
be less confusion as to what a user is actually using.
Note: this feature requires Ruby 2.1 and later for non-kgio
{read,write}_nonblock(.. exception: false) support.
|
|
No need to waste space on this (and trigger "Bad partial
reference!" warnings on lynx)
|
|
This test is less reliable when there are multiple workers as the
second worker may not be ready to detect a dead parent.
This is still a possible race if the master dies very quicklly
before a worker is fully setup.
|
|
Followup-to commit ade89b5142bedbcf07f38aa062bfdbfcb8bc48d3
("wbuf: hack to avoid response corruption on FreeBSD")
It seems that we cannot test wbuf internals reliably outside of
Linux, however as long as the end result (via HTTP) is unchanged
on other OSes, we seem to be doing OK.
|
|
GC will close redundantly and lead to EBADF when finalizing. This was
probably harmless as the original IO objects remained marked; but do
not count on it. Seeing EBADF in a MT process is a very bad sign
(inadvertant information disclosure is only one race condition away).
Fortunately, this bug was limited to our test suite :)
|
|
There's a feature request for better coverage support in ruby-trunk
https://bugs.ruby-lang.org/issues/9508
At minimum, we need to preserve compatibility; but we should set
aside time to take advantage of the extra coverage support.
|
|
|
|
TCP socket timing is too varied over different OSes, Unix sockets
seem to test more reliably than TCP ones on my Debian GNU/kFreeBSD
system.
|
|
Not all TCP stacks behave the same with timing-sensitive tests.
Fortunately these timing differences aren't very critical over real
networks.
|
|
We may unnecessarily drop persistent connections from this bug,
and we had an incorrect assertion in our unit test, even.
|
|
We must not cork response headers when the response body is empty,
otherwise those headers will be delayed by 200ms.
|
|
If Content-Length is known, try to save some bandwidth by
corking the headers until the body is sendable. This allows
us to avoid sending an extra packet for small HTTP responses.
This allows high-performance websites like YHBT.net to be served
faster!
|