| Date | Commit message (Collapse) |
|---|
|
Tested with the following example patch over a slow connection:
--- a/examples/the_metal.rb
+++ b/examples/the_metal.rb
@@ -10,7 +10,7 @@ class Application
# when write_head is called or have Transfer-Encoding: chunked
# (in which case res.write must chunk for us)
res.write_head 200, 'Content-Type' => 'text/plain'
- res.write "Hello World\n"
+ 1000000.times { res.write "Hello World\n" }
res.finish
end
end
|
|
ref: the_metal commit 26527612c7a227fa2b53dd7158408ae48d2c57ea
"use `call` instead of `serve`"
|
|
ref: git://github.com/tenderlove/the_metal.git
|
|
* updated kqueue support status
* noted sbrk/mmap scalability issue
* speling fiks ("optimally")
* indent "git clone" invocation
* updated copyright status
|
|
We should no longer need HTTP parser or input body upon hijacking.
Remove references to it so the GC can clean those up. This relies
on the Rack application deleting "rack.input" from the Rack env,
too.
|
|
This release contains a major bug fix noticeable on FreeBSD VMs, but
should affect Linux systems making large responses which require
output buffering, too.
* test_server: avoid multiple workers for dead parent check
* wbuf: avoid corrupted large responses with zero-copy sendfile
|
|
This bug is noticeable on a amd64 FreeBSD 9.2 VM, and possible under
Linux, too. This happens as a zero-copy sendfile implementation means
pages queued for transmission by the sendfile system call should not be
modified at any point after the sendfile syscall is made.
To prevent modification, we replace the temporary file with a new one.
This has a similar effect as truncate and can still prevent a dirty
flush in cases when a client consumes the response fast enough.
This reverts the misguided ade89b5142bedbcf07f38aa062bfdbfcb8bc48d3
commit ("wbuf: hack to avoid response corruption on FreeBSD")
Note: this bug was finally fixed because I finally noticed this flaw
in a different (non-Ruby, non-HTTP) server of mine.
|
|
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.
|
|
Since RubyForge is going away, this release updates the
documentation to point to the new public-inbox and mailing list
at at:
yahns-public@yhbt.net
(no subscription required, plain text only)
ssoma[1] git archives: git://yhbt.net/yahns-public
browser-friendly archives: http://yhbt.net/yahns-public/
Traditional mailing list subscription is possible by sending
a blank email to: yahns-public+subscribe@yhbt.net
This also reworks master->worker signalling to use a pipe,
avoiding problems with libraries which do not respond well
to being interrupted by signals. There are also minor
bugfixes and cleanups, see "git log -p" for full details.
[1] http://ssoma.public-inbox.org/
|
|
A follow-up-to commit 0c20f34c3d54e1c3d7b7a811c401e6858196e8a7
("rework master-to-worker signaling to use a pipe"), there is
no reason to use a real kill(2) here.
|
|
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.
|
|
This quiets down our logs when acceptors do not die quickly
enough for us.
|
|
This prevents potential errors and compatibility problems with
buggy libraries which do not respond well to signal delivery.
Based on unicorn commit 6f6e4115b4bb03e5e7c55def91527799190566f2
|
|
There's almost no chance of blocking here, but better to
be safe than sorry inside signal handlers. We would
get the wakeup even if the pipe/event fd blocks.
|
|
We do this for conciseness.
|
|
When daemonizing, it is possible for the grandparent to be
terminated by another process before the master can notify
it. Do not abort the master in this case.
unicorn commit 27ae210dde9228cfa96ea6b0f3a7e4047d3f70a4
|
|
Rubyforge is going away on May 15, so update our docs for it.
|
|
Much of this code was copied from the epoll queue.
|
|
Using the full, filesystem path name to our script is wrong
and not according to RFC 3875.
|
|
Sometimes a CGI script wants to run with some environment
variables set or overridden. Allow it.
|
|
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 :)
|
|
This release now depends on "kgio-sendfile", a (hopefully temporary)
fork of the original sendfile gem for mainline ruby trunk
compatibility and a (probably correct) FreeBSD-related bugfix.
kqueue/FreeBSD support is considered highly experimental. Of course;
you should never rely on anything in production unless you can get bugs
fixed in every part of your stack; even the kernel. yahns (ab)uses
kqueue and epoll in uncommon ways, so you may encounter subtle kernel
bugs along the way.
Because yahns has been self-hosting its own website for months without
crashes or major problems (BORING! :P), I've decided to start hosting the
yahns website <http://yahns.YHBT.net/README> with ruby trunk (currently
r45341).
yahns - dangerous by design (and sleepy!)
|
|
We favor foo(&:bar) when possible for conciseness.
|
|
This likely makes no difference in 99% of real world situations with
fast response generation. The only case where lack of output buffer
bypass makes a difference is when the following sequence happens:
1) a giant response cannot fit into socket buffers
2) temporary file created for buffering
3) client consumes output so we get more space in socket buffers
4) app response generation continues (streaming response)
5) we successfully write _all_ previously buffered data to socket
6) we may bypass buffering for data generated in step 4
So right now, we cannot do step 6 outside of Linux. Instead, once an
output buffer is created; we must always write to the output buffers.
|
|
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.
|
|
* origin/freebsd:
implement kqueue and sendfile compatibility support
test: log skipped tests on non-Linux systems
test_server: check_client_connection uses Unix sockets
test_client_expire: add delays for non-Linux OSes
wbuf_common: avoid trysendfile on empty sf_count
sigevent_pipe: kgio_wait_writable takes variadic args
queue_quitter_pipe: do not prematurely close reader
|
|
Hopefully kgio-sendfile is only a temporary fork until
Toby gets back to maintaining the normal sendfile gem.
|
|
Tested on Debian GNU/kFreeBSD (sid):
make check SENDFILE_BROKEN=1
|
|
|
|
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 may pass a timeout to kgio_wait_writable during shutdown.
|
|
This will lead to ENOENT when placing writer into kqueue
changelist via kevent(2)
|
|
On responses with a known, non-zero Content-Length, yahns will now
automatically use the MSG_MORE flag when sending HTTP headers. This
reduces TCP packet transmits and allows clients to wake up and read
one less time.
This is similar to the TCP_NOPUSH/TCP_CORK functionality of other
servers, but requires no additional syscalls. It is only supported
on the Linux kernel, however (but yahns is currently epoll-only
with kqueue support on the horizon).
Eric Wong (5):
quiet down EHOSTUNREACH errors
http_response: use kgio_syssend with MSG_MORE
load yahns/version file
socket_helper: remove SO_REUSEPORT define for untested arches
response: do not use MSG_MORE on empty bodies
|
|
We must not cork response headers when the response body is empty,
otherwise those headers will be delayed by 200ms.
|
|
We'll let systems with updated glibc headers define those
(or interested users, if any, on those architectures test
and report back to us). No point in causing unnecessary
breakage if we screw things up.
|
|
We need this for "yahns --version" on the command line
|
|
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!
|
|
We can't do anything about EHOSTUNREACH, so quiet the backtrace.
I've noticed this happening very rarely (once every few weeks?)
while yahns was exposed to untrusted traffic.
|
|
Mostly fixes for the extras/* stuff running on yahns.YHBT.net and
documentation/packaging fixes. Anyways, this is hosting the
yahns website for a while now (running rack.git) without any
major issues.
Also, the mailing list will need to move/change because Rubyforge is
going away. Everything I said for the unicorn ML applies to this list,
too: http://mid.gmane.org/20131217015614.GB1125@dcvr.yhbt.net
|
|
Unicorn::HttpResponse#httpdate is currently not thread-safe without GVL.
|
|
Proper POSIX filesystems are encoding-agnostic.
|
|
ab(1) is less common than our other dependencies, so allow tests
to run without it.
|
|
unicorn uses semantic versioning, and we are compatible
with 4.7.0, so use it.
|
|
Having two ~> dependencies doesn't OR the dependency as intended.
In either case, assume 6.x is not compatible out-of-the box and
do not enable it. While we're at it, document our dependency
policy for the test library.
|
|
We will override it internally regardless of middlewares.
|
|
This was causing zombies on the bogomips.org cgit instance.
|
|
We do not use these strings in string assignment, and we're not
in danger of modifying these strings in place, so do not freeze
them.
|
|
The body may contain extra repeated newlines, of course
|