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 rubyforge.org * git://git.bogomips.org/unicorn.git Changes: Starting with this release, we''ll always load Rack up front at startup. Previously we had complicated ways to avoid loading Rack until after the application was loaded to allow the application to load an alternate version of Rack. However this has proven too error-prone to be worth supporting even though Unicorn does not have strict requirements on currently released Rack versions. If an app requires a different version of Rack than what Unicorn would load by default, it is recommended they only install that version of Rack (and no others) since Unicorn does not have any strict requirements on currently released Rack versions. Rails 2.3.x users should be aware of this as those versions are not compatible with Rack 1.1.0. If it is not possible to only have one Rack version installed "globally", then they should either use Isolate or Bundler and install a private version of Unicorn along with their preferred version of Rack. Users who install in this way are recommended to execute the isolated/bundled version of Unicorn, instead of what would normally be in $PATH. Feedback/tips to mailto:mongrel-unicorn at rubyforge.org from Isolate and Bundler users would be greatly appreciated. Thanks to Aaron Eisenberger for making us aware of this issue. -- Eric Wong
Re: bundling/isolating:> If it is not possible to only have one Rack version installed > "globally", then they should either use Isolate or Bundler and > install a private version of Unicorn along with their preferred > version of Rack. Users who install in this way are recommended > to execute the isolated/bundled version of Unicorn, instead of > what would normally be in $PATH.A caveat about using a bundled unicorn binary (via `bundle exec unicorn`): if you use capistrano-based deployment, make sure to use a shared vendor/bundler_gems! Obviously this is much faster than re-bundling each release, but it also prevents the unicorn binary from going missing -- if unicorn is originally executed as /app/releases/XXY/vendor/bundler_gems/bin/unicorn and that release gets rolled back or pruned by :keep_releases, the original master''s binary is now gone & it will no longer be able to fork new unicorn masters (is this expected behavior/a known issue?) -jamie
Jamie Wilkinson <jamie at internetfamo.us> wrote:> Re: bundling/isolating: > > > If it is not possible to only have one Rack version installed > > "globally", then they should either use Isolate or Bundler and > > install a private version of Unicorn along with their preferred > > version of Rack. Users who install in this way are recommended to > > execute the isolated/bundled version of Unicorn, instead of what > > would normally be in $PATH. > > A caveat about using a bundled unicorn binary (via `bundle exec > unicorn`): if you use capistrano-based deployment, make sure to use a > shared vendor/bundler_gems!Thanks for the tip!> Obviously this is much faster than re-bundling each release, but it > also prevents the unicorn binary from going missing -- if unicorn is > originally executed as > /app/releases/XXY/vendor/bundler_gems/bin/unicorn and that release > gets rolled back or pruned by :keep_releases, the original master''s > binary is now gone & it will no longer be able to fork new unicorn > masters (is this expected behavior/a known issue?)Yeah, Unicorn will stash the original command-line it was executed with. If you need to override this at runtime, I would do something like this in the Unicorn config file: Unicorn::HttpServer::START_CTX[0] = "/some/path/to/bin/unicorn" -- Eric Wong