similar to: Nightmare! - an nginx alternative for unicorn

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: Rewindable "rack.input" may be disabled via the "rewindable_input false" directive in the configuration file. This will violate Rack::Lint for Rack 1.x applications, but can reduce I/O for applications that do not need a rewindable input. This release updates us to the Kgio 2.x series which should play more nicely with other libraries and applications. There 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

This allows users to start an independent instance of unicorn on a the same port as a running unicorn (as long as both instances use :reuseport). ref: https://lwn.net/Articles/542629/ --- lib/unicorn/configurator.rb | 19 +++++++++++++++++++ lib/unicorn/socket_helper.rb | 30 ++++++++++++++++++++++-------- test/unit/test_socket_helper.rb | 8 ++++++++ 3 files changed, 49 insertions(+), 8

I am using nginx with unicorn as a reverse proxy. Has been fantastic, but needed to look through some code for first time. Using ruby 1.9.3p194 with rails 3.2.9, development mode with ssl enabled, I start unicorn with -d ...and it does not get served up by nginx. Any ideas, or more information needed? Thanks! Jet Below is my unicorn.rb for developent: # config/unicorn.rb env =

Signaling using normal kill(2) is preserved, but the master now prefers to signal workers using a pipe rather than kill(2). Non-graceful signals (:TERM/:KILL) are still sent using kill(2), as they ask for immediate shutdown. This change is necessary to avoid triggering the ubf (unblocking function) for rb_thread_call_without_gvl (and similar) functions extensions. Most notably, this fixes

Hello all, I''m wondering if you deploy nginx: 1) on the same machine that runs unicorn (exclusively proxying to that) 2) on a different machine that doesn''t run unicorn 3) both, nginx could forward to either to localhost or another host on the same LAN And of course, the reason(s) you chose what you chose. I''m inclined to believe many folks are on 1) simply

On Mon, Jan 21, 2013 at 11:28 AM, Eric Wong <normalperson at yhbt.net> wrote: > Charles Hornberger <charles.hornberger at gmail.com> wrote: >> Hi! >> >> I recently noticed this error message when restarting unicorn after a >> code deployment (and I don''t think I recall having seen it before): >> >> I, [2013-01-18T17:54:21.502554 #59285]

I''ve setup nginx with this server { listen 80; server_name unicorn.local; location / { proxy_pass http://unicorn; } } upstream unicorn { server unix:/Users/mattmongeau/projects/test/unicorn/tmp/sockets/unicorn.sock; } When I run unicorn_rails -c config/unicorn.rb -E development I can access the application just fine on unicorn.local When I run unicorn_rails -c

Hi, Unicorn is saying it''s terminating but it''s not actually. Check out the gist:?https://gist.github.com/1104930 Using: - Ruby 1.9.2p180 - unicorn 4.0.1 - kgio 2.6.0 - bundler 1.0.15 - Linux maynard 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:07:17 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux Please let me know if there''s any other info I can provide. Thanks, Jesse

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) +

Switched my RoR (3.1.3, 1.9.2) app from Thin to Unicorn (4.6.2). It ran fine in development (Mac OSX), but when deploying to production on Heroku, it fails silently (no backtrace, no error detail). Log looks like: Starting process with command `bundle exec unicorn start -p 6069 -c ./config/unicorn.rb` /app/vendor/bundle/ruby/1.9.1/gems/unicorn-4.6.2/lib/unicorn/configurator.rb:634:in

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

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

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

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

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

Hi, I''m deploying Unicorn on a Rails application with RUnit. Technically I''m using Chef''s deployment tools, if any of you are familiar with it (https://github.com/opscode-cookbooks/application_ruby) but to be clear they aren''t doing anything magical, so this is purely an issue with RUnit and Unicorn. The TL;DR of the following post, which has lots of

Hi, I''m currently giving Nginx + Unicorn a try, to eventually replace Apache + Passenger. So far so good. I have a Rails 3.2.5 app behind Unicorn, itself behind Nginx. In this Rails app, I have set page caching for some resources. They are created in Rails.root/public/ to be directly available to Nginx. When I first hit such a page, the static cache file is not present, so the Rails

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