Re: About Unicorn Rack handler

[Eric Wong <normalperson@yhbt.net>]

"Lin Jen-Shin (aka godfat 真常)" <godfat@godfat.org> wrote:
> On Thu, Nov 5, 2009 at 1:07 AM, Eric Wong <normalperson@yhbt.net> wrote:
> > I think making Unicorn.run add to :listeners if :Host or :Port are set
> > will work.  I'm not sure if launching Unicorn directly from `rackup' can
> > ever work right without being too intrusive to the other servers, so
> > having a Unicorn Rack handler in distributed with Rack would't make
> > sense.   Unicorn needs to capture ARGV (before option parsing) and parse
> > its own config file, neither of which is doable out-of-the-box with
> > rackup.
> 
> I see. On the other hand, it would be great if `rackup' could work with
> Unicorn directly. Perhaps something like:
> 
>   rackup -r config/unicorn.rb -s unicorn -p 12345 config.ru

As I explained in the other email, this unfortunately can't ever give
you all the features that Unicorn has.

I've made an effort to keep everything else as compatible and the
migration paths as easy as possible.

> I would want this because I have a rackup cluster script.
> If this would work, then I don't have to change the existing
> script to adapt to Unicorn with a -c option, along with
> changing `rackup' to `unicorn'.
> 
> Here's the script:
> http://github.com/godfat/app-deploy/blob/master/lib/app-deploy/rack_cluster.rb
> 
> Here's an example config for `rack_cluster':
> http://github.com/godfat/app-deploy/blob/master/example/rack_cluster.yaml
> 
> I know I won't need rack "cluster" once I switch to Unicorn.
> Perhaps what I should do is just drop rack cluster support,
> then many things could be simplified.

Yeah, it's probably simpler to just use "unicorn" than to wrap it.

It's really hard use the process management functionality in a libified
form since we rely on things like $0 and ARGV.  On the other hand, since
Unicorn is designed to work with nginx, you can use the same
scripts/signals for managing both.

> > Does something like this work? (not tested).
> >
> > diff --git a/lib/unicorn.rb b/lib/unicorn.rb
> > index 0f2b597..d4a00e0 100644
> > --- a/lib/unicorn.rb
> > +++ b/lib/unicorn.rb
> > @@ -17,6 +17,14 @@ module Unicorn
> >
> >   class << self
> >     def run(app, options = {})
> > +      # compatibility with other interfaces (Ramaze)
> > +      host = options.delete(:Host)
> > +      port = options.delete(:Port)
> > +      if host || port
> > +        port ||= Const::DEFAULT_PORT
> > +        host ||= Const::DEFAULT_HOST
> > +        (options[:listeners] ||= []) << "#{host}:#{port}"
> > +      end
> >       HttpServer.new(app, options).start.join
> >     end
> >   end
> 
> Yes, work fine at first try. Many thanks for your work!
> The working `start.rb' for Ramaze is:
> 
>   require 'unicorn'
>   Rack::Handler.register('unicorn', 'Unicorn')
>   Ramaze.start(:adapter => 'unicorn', :port => 7000)
> 
> > On the other hand, does Innate make it possible to do transparent
> > upgrades (since rackup does not)?  I'll look into it a bit more later...
> 
> I am not sure what do you mean transparent here,

Can you try and see if the USR2 handling of Unicorn allows
a transparent upgrade here?  If it doesn't then I don't think
it's worth supporting an interface that's crippled compared
to using the plain `unicorn' command.

-- 
Eric Wong
_______________________________________________
mongrel-unicorn mailing list
mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn