similar to: Quick question about bogomips.org

Unicorn is a Rack HTTP server for Unix, fast clients and nothing else[1] We now have support for "Transfer-Encoding: chunked" bodies in requests. Not only that, Rack applications reading input bodies get that data streamed off to the client socket on an as-needed basis. This allows the application to do things like upload progress notification and even tunneling of arbitrary stream

Consider this a joke until somebody who knows crypto well can review it (_and_ kgio-monkey[1]). I know it works with curl (test case included) and I can''t see plain-text when I strace/tcpdump, that''s about it :) Subject: [PATCH] add preliminary SSL support This will also be the foundation of SSL support in Rainbows! and Zbatery. Some users may also want to use this in Unicorn

Changes: The new check_client_connection option allows unicorn to detect most disconnected local clients before potentially expensive application processing begins. This feature is useful for applications experiencing spikes of traffic leading to undesirable queue times, as clients will disconnect (and perhaps even retry, compounding the problem) before unicorn can even start processing the

This is a slow client buffering layer which may be used instead of nginx to protect Unicorn from slow clients. Nightmare! will _never_ beat nginx in raw throughput nor performance. It /may/ be easier to setup than nginx and a suitable alternative to Rainbows! for users who do not wish to maintain a thread-safe/async-safe Rack application. Code changes to the existing Unicorn codebase are

Hello all, I''ve released kgio, a kinder, gentler I/O library for Ruby. Some of its features are useful for Unicorn, and all of it is useful for Rainbows! I intend to make kgio a requirement for both Unicorn and Rainbows!/Zbatery. I''m comfortable with the code, but extra testers and extra eyes to review it would be helpful (it''s nearly all C). There were several

Unicorn is an HTTP server for Rack applications designed to only serve fast clients on low-latency, high-bandwidth connections and take advantage of features in Unix/Unix-like kernels. Slow clients should only be served by placing a reverse proxy capable of fully buffering both the the request and response in between Unicorn and slow clients. * http://unicorn.bogomips.org/ * mongrel-unicorn at

Unicorn is an HTTP server for Rack applications designed to only serve fast clients on low-latency, high-bandwidth connections and take advantage of features in Unix/Unix-like kernels. Slow clients should only be served by placing a reverse proxy capable of fully buffering both the the request and response in between Unicorn and slow clients. * http://unicorn.bogomips.org/ * mongrel-unicorn at

If unicorn doesn''t get terminated cleanly (for example if the machine has its power interrupted) and the pid in the pidfile gets used by another process, the current unicorn code will exit and not start a server. This tiny patch fixes that behaviour. --- lib/unicorn/http_server.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/unicorn/http_server.rb

Unicorn is a HTTP server for Rack applications designed to only serve fast clients on low-latency, high-bandwidth connections and take advantage of features in Unix/Unix-like kernels. Slow clients should only be served by placing a reverse proxy capable of fully buffering both the the request and response in between Unicorn and slow clients. * http://unicorn.bogomips.org/ * mongrel-unicorn at

Unicorn is a HTTP server for Rack applications designed to only serve fast clients on low-latency, high-bandwidth connections and take advantage of features in Unix/Unix-like kernels. Slow clients should only be served by placing a reverse proxy capable of fully buffering both the the request and response in between Unicorn and slow clients. * http://unicorn.bogomips.org/ * mongrel-unicorn at

Unicorn is a HTTP server for Rack applications designed to only serve fast clients on low-latency, high-bandwidth connections and take advantage of features in Unix/Unix-like kernels. Slow clients should only be served by placing a reverse proxy capable of fully buffering both the the request and response in between Unicorn and slow clients. * http://unicorn.bogomips.org/ * mongrel-unicorn at

Mainly small fixes, improvements, and workarounds for fork() issues with pseudo-random number generators shipped with Ruby (Kernel#rand, OpenSSL::Random (used by SecureRandom and also by Rails). If there are any other fixes/improvements that could be useful let us know. I think this is nearing the end of the line for the 3.x series which will then go into maintenance mode. I''m looking

Changes: Our attempt in 3.6.0 to workaround a problem with the OpenSSL PRNG actually made the problem worse. This release corrects the workaround to properly reseed the OpenSSL PRNG after forking. Thanks to ghazel for the report! * http://unicorn.bogomips.org/ * mongrel-unicorn at rubyforge.org * git://bogomips.org/unicorn.git -- Eric Wong

This release enables tuning the client_buffer_body_size to raise or lower the threshold for buffering request bodies to disk. This only applies to users who have not disabled rewindable input. There is also a TeeInput bugfix for uncommon usage patterns and Configurator examples in the FAQ should be fixed. * http://unicorn.bogomips.org/ * mongrel-unicorn at rubyforge.org *

I don''t know if there are any folks wrapping Unicorn, but I''ve removed the Unicorn.run method in unicorn.git as part of an effort to reduce stack size (which will improve GC performance and reduce the cost of generating (and examining) backtraces. You can replace: Unicorn.run(app, options) With: Unicorn::HttpServer.new(app, options).start.join This will be in the

Installing from RubyGems.org: gem install --pre unicorn >From db919d18e01f6b2339915cbd057fba9dc040988b Mon Sep 17 00:00:00 2001 From: Eric Wong <normalperson at yhbt.net> Date: Tue, 29 Jan 2013 21:02:55 +0000 Subject: [PATCH] unicorn 4.6.0pre1 - hijacking support This pre-release adds hijacking support for Rack 1.5 users. See Rack documentation for more information about hijacking.

First off thanks very much for all the hard work on unicorn. Alas, we''ve encountered an issue where unicorn fails to spawn new workers that have loaded the incoming revision on a capistrano deploy. I''m not entirely sure the issue is due to unicorn as it appears that bundler was responsible for a similar issue in the past:

We''ve run into this problem several times and it''s not really expected that someone is going to monkey with /dev/null. So here''s a simple patch. I am not on the mailing list, so please Cc: me. --- lib/unicorn/util.rb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/unicorn/util.rb b/lib/unicorn/util.rb index cde2563..6b6cca2 100644 ---

Streaming works with Unicorn + Apache. Both with and without deflating. My understanding is that Unicorn + Apache is not a good combination though because Apache does not buffer, and thus Unicorn has no fast client in front. (I don''t know which is the ultimate technical reason Unicorn puts such an emphasis on fast clients, but will do some research about it.) I have seen in

This means we no longer waste an extra file descriptor per worker process in the master. Now there''s no need to set a higher file descriptor limit for systems running >= 1024 workers. --- I just pushed this out to git://bogomips.org/unicorn.git and it''ll be in Unicorn 4.x. The subset of raindrops used by Unicorn should work on all machines with mmap(2) +