similar to: ṿῒạğřạ

--- lib/unicorn/configurator.rb | 2 +- lib/unicorn/http_server.rb | 6 +++++- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/lib/unicorn/configurator.rb b/lib/unicorn/configurator.rb index 89cbf5c..c9b6816 100644 --- a/lib/unicorn/configurator.rb +++ b/lib/unicorn/configurator.rb @@ -559,7 +559,7 @@ private def set_path(var, path) #:nodoc: case path - when

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

I have strange error that happens after couple of hours. Some instances start to respond on any request with status code 500. Log file unicorn.stderr.log gets populated with this error: app error: undefined method `each'' for nil:NilClass (NoMethodError) /usr/local/lib/ruby/gems/1.9.1/gems/rack-1.1.2/lib/rack/utils.rb:267:in `initialize''

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

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

I am wondering if there are any apps affected by this bug (and perhaps keeping people from switching Unicorn). It''s a fairly esoteric case, so I probably won''t make another release until tomorrow (sleepy now, will probably screw something else up or realize something else is broken :) Anyways it''s pushed out to master and 1.1.x-stable in case people want^Wneed it

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

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 =

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

I''ve been meaning to test this setup somewhere for a while, but never got the right app/(real) traffic/hardware to do it with. So maybe somebody can try it out and let us know if this works... It''s for applications running the same code/data on a cluster of machines, so this doesn''t apply to the majority of low-traffic sites out there. The goal is to avoid having to

If you''re getting an EBADF (bad file descriptor) error when re-execing Unicorn under Ruby >= 2.0 (see, e.g, http://rubyforge.org/pipermail/mongrel-unicorn/2013-August/001858.html), it''s likely that you''re re-running Unicorn via "bundle exec": http://developer.zendesk.com/blog/2013/10/09/ruby-2-0-changes-exec-bundler/ The fix is to use a binstub for

Some of you may have noticed the "rainbows" branch of the git repository. I may be changing that however and making a small group of gems (or even one gem) that can get loaded at runtime and monkey patch parts of Unicorn. Rainbows will primarily be to support things Unicorn sucks at: 1. apps that rely on out-of-datacenter network connections (CAPTCHA services, OpenID, real-time

We now give an example of how a before_fork hook can be used to incrementally migrate off the old code base without hitting a thundering herd (especially in the "preload_app false") case. Also comment on the per-worker listen usage in the RDoc, not just a hidden comment. --- I just pushed this out earlier, this example was inspired by Chris Wanstrath''s before_fork hook but

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 Ian, I also found this address in the git history, hoping this works since ian at inspir.es doesn''t. ----- Forwarded message from Eric Wong <normalperson at yhbt.net> ----- From: Eric Wong <normalperson at yhbt.net> To: mongrel-unicorn at rubyforge.org Cc: Hongli Lai <hongli at phusion.nl>, Augusto Becciu <augusto at jadedpixel.com>, I?aki Baz Castillo

Hi all, I''m fighting with the after_fork hook and my sinatra application. The Sinatra app is using active_record, In my unciron.rb file I''m using preload_app true after_fork do |server, worker| ? defined?(ActiveRecord::Base) and ??? ActiveRecord::Base.establish_connection End but I always get the error: ERROR -- : ActiveRecord::AdapterNotSpecified

Hi folks, I''ve experimented a problem while deploying my app, I''ve sent the HUP signal to the master process, I''ve checked everything is ok: new master and workers are spawned and the old ones are killed(I''ve checked the PIDs), but the new code deployed isn''t reflected in the living site, so I''ve to stop and start again unicorn in order to see