Mongrel development - Feb 2009 - Unicorn: UNIX+localhost/LAN-only Mongrel fork

Hello all,

Last week, I finally decided to put into motion some ideas I''ve been
kicking around for a year in my head since last year...

Basically I don''t want to have to deal with threads or support
platforms
that rely on or encourage threads.  Especially given MRI 1.9 where
kernel threads are more difficult to debug than green ones.

Given the limited scope of this project, I''m thinking it''s
better to be
a part of the Mongrel project since there is shared code and use
the Mongrel Rubyforge account for distributing tarballs/gems.

I don''t have the resources or drive to manage things like support,
documentation, bug-trackers myself.  Being a UNIX terminal fart, I still
find the web-based things painful to use.  The source is under the same
license as Mongrel and in git (see below) so feel free to contribute :)

Of course I''ve yet to actually thoroughly test, deploy real
applications
or even run benchmarks on Unicorn.  That''ll probably happen later today
or tomorrow...

Here''s the README (also at http://unicorn.bogomips.org/)
git repository locations are in there, as well.
------------------------------- 8< ----------------------------
= Unicorn: UNIX + LAN/localhost-only fork of Mongrel

Only run this behind a full-HTTP-request-buffering reverse proxy if
you''re serving slow clients.  That said, nginx is the only reverse
proxy we know of that meets this requirement.

== Features

 * process management: Unicorn will reap and restart workers that
   die because of broken apps and there is no need to manage
   multiple processes yourself.

 * doesn''t matter if your application is thread-safe or not, workers
   all run within their own isolated address space and only serve one
   client at a time...

 * able to listen on multiple interfaces, including UNIX sockets,
   each worker process can also bind to a private port via the
   after_fork hook for easy debugging.

 * should support all Rack applications (though only Sinatra has been tested)

 * nginx-style binary re-execution without losing connections.
   You can upgrade unicorn, your entire application, libraries
   and even your Ruby interpreter as long as unicorn is
   installed in the same path

 * before_fork and after_fork hooks in case your application
   has special needs when dealing with forked processes.  These
   can be used to setup signal handlers for logrotation, too.

 * Ruby 1.9-compatible (at least the test cases all pass :>)

== Design

 * Simplicity: Unicorn is a traditional UNIX prefork web server.
   No threads are used at all, this makes applications easier to debug
   and fix.  When your application goes awry, a BOFH can just
   "kill -9" the runaway worker process without worrying about tearing
   all clients down, just one.  Only UNIX-like systems supporting
   fork() and file descriptor inheritance is supported.

 * The Ragel->C HTTP parser is taken from Mongrel.  This is the
   only non-Ruby part and there are no plans to add any more
   non-Ruby components.

 * All HTTP protocol parsing and I/O is done just like Mongrel:
   1. read/parse HTTP request in full
   2. call Rack application
   3. write HTTP response back to the client

 * Like Mongrel, neither keepalive nor pipelining are supported.
   These aren''t needed since Unicorn is only designed to serve
   fast, low-latency clients directly.  Do one thing, do it well;
   let nginx handle slow clients.

 * Configuration is purely in Ruby and eval().  Ruby is less
   ambiguous than YAML and lets lambdas for before_fork/after_fork
   hooks be defined inline.  An optional, separate hot_config_file
   may be used to modify supported configuration changes
   (and also gives you plenty of rope if you RTFS :>)

 * One master process spawns and reaps worker processes.  The
   Rack application itself is called only within the worker process (but
   can be loaded within the master).  A copy-on-write friendly garbage
   collector like Ruby Enterprise Edition can be used to minimize memory
   usage.

 * The number of worker processes should be scaled to the number of
   CPUs, memory or even spindles you have.  If you have an existing
   Mongrel cluster, using the same amount of processes should work.
   Let a full-HTTP-request-buffering reverse proxy like nginx manage
   concurrency to thousands of slow clients for you.  Unicorn scaling
   should only be concerned about limits of your backend system(s).

 * Load balancing between worker processes is done by the OS kernel.
   All workers share a common set of listener sockets and does
   non-blocking accept() on them.  The kernel will decide which worker
   process to give a socket to and workers will sleep if there is
   nothing to accept().

 * Since non-blocking accept() is used, there can be a thundering
   herd when an occasional client connects when application
   *is not busy*.  The thundering herd problem should not affect
   applications that are running all the time since worker processes
   will only select()/accept() outside of the application dispatch.

 * Blocking I/O is used for clients.  This allows a simpler code path
   to be followed within the Ruby interpreter and fewer syscalls.
   Applications that use threads should continue to work if Unicorn
   is serving LAN or localhost clients.

 * Timeout implementation is done via fchmod(2) in each worker
   on a shared file descriptor to update st_ctime on the inode.
   Master process wakeups for checking on timeouts is throttled
   one a second to minimize the performance impact and simplify
   the code path within the worker.  Neither futimes(2) nor
   pwrite(2)/pread(2) are supported by base MRI, nor are they as
   portable on UNIX systems as fchmod(2).

 * SIGKILL is used to terminate the timed-out workers as reliably
   as possible on a UNIX system.

 * The poor performance of select() on large FD sets is avoided
   as few file descriptors are used in each worker.
   There should be no gain from moving to highly scalable but
   unportable event notification solutions for watching few
   file descriptors.

 * Since workers only work on one client at a time, the temporary
   file for storing large POST/PUT requests is reused for the
   lifetime of the process.  This should limit temp directory
   growth on UNIX filesystems where temp file names are never
   purged from the containing directory.

 * If the master process dies unexpectedly for any reason,
   workers will notice within :timeout/2 seconds and follow
   the master to its death.

== License

Unicorn is copyright 2009 Eric Wong and contributors.
It is based on Mongrel:

Mongrel is copyright 2007 Zed A. Shaw and contributors. It is licensed
under the Ruby license and the GPL2. See the include LICENSE file for
details.

== Install

The library consists of a C extension so you''ll need a C compiler or at
least a friend who can build it for you.

Finally, the source includes a setup.rb for those who hate RubyGems.

You can get the source via git via the following locations:

  git://git.bogomips.org/unicorn.git

  http://git.bogomips.org/unicorn.git

== Usage

See the Sinatra example.

It should be capable of running all Rack applications.  Since this
is a preforking webserver

== Contact

Newsgroup and mailing list coming, or it''ll be a part of the Mongrel
project...

Email Eric Wong at normalperson at yhbt.net for now.
------------------------------- 8< ----------------------------

Eric,

this sounds great.

what would you think of adding an option to allow the server to
connect to one (or more?) unix pipes for process restart instructions?
i''d love to add a nginx module which notices when a backend is
responding too slowly and can notify Unicorn to restart it. (this is
the killer feature of passenger phusion.)

a simple protocol where a single byte message encodes the index of the
backend that needs to be restarted would work i think (easy to
multiplex with multiple writer processes)

ry

This is really cool. I''m going to play with this now and see how it  
works.

Cheers
-Ezra


On Feb 11, 2009, at 3:04 PM, Eric Wong wrote:
> Hello all,
>
> Last week, I finally decided to put into motion some ideas I''ve
been
> kicking around for a year in my head since last year...
>
> Basically I don''t want to have to deal with threads or support  
> platforms
> that rely on or encourage threads.  Especially given MRI 1.9 where
> kernel threads are more difficult to debug than green ones.
>
> Given the limited scope of this project, I''m thinking
it''s better to
> be
> a part of the Mongrel project since there is shared code and use
> the Mongrel Rubyforge account for distributing tarballs/gems.
>
> I don''t have the resources or drive to manage things like support,
> documentation, bug-trackers myself.  Being a UNIX terminal fart, I  
> still
> find the web-based things painful to use.  The source is under the  
> same
> license as Mongrel and in git (see below) so feel free to  
> contribute :)
>
> Of course I''ve yet to actually thoroughly test, deploy real  
> applications
> or even run benchmarks on Unicorn.  That''ll probably happen later
> today
> or tomorrow...
>
> Here''s the README (also at http://unicorn.bogomips.org/)
> git repository locations are in there, as well.
> ------------------------------- 8< ----------------------------
> = Unicorn: UNIX + LAN/localhost-only fork of Mongrel
>
> Only run this behind a full-HTTP-request-buffering reverse proxy if
> you''re serving slow clients.  That said, nginx is the only reverse
> proxy we know of that meets this requirement.
>
> == Features
>
> * process management: Unicorn will reap and restart workers that
>   die because of broken apps and there is no need to manage
>   multiple processes yourself.
>
> * doesn''t matter if your application is thread-safe or not,
workers
>   all run within their own isolated address space and only serve one
>   client at a time...
>
> * able to listen on multiple interfaces, including UNIX sockets,
>   each worker process can also bind to a private port via the
>   after_fork hook for easy debugging.
>
> * should support all Rack applications (though only Sinatra has been  
> tested)
>
> * nginx-style binary re-execution without losing connections.
>   You can upgrade unicorn, your entire application, libraries
>   and even your Ruby interpreter as long as unicorn is
>   installed in the same path
>
> * before_fork and after_fork hooks in case your application
>   has special needs when dealing with forked processes.  These
>   can be used to setup signal handlers for logrotation, too.
>
> * Ruby 1.9-compatible (at least the test cases all pass :>)
>
> == Design
>
> * Simplicity: Unicorn is a traditional UNIX prefork web server.
>   No threads are used at all, this makes applications easier to debug
>   and fix.  When your application goes awry, a BOFH can just
>   "kill -9" the runaway worker process without worrying about
tearing
>   all clients down, just one.  Only UNIX-like systems supporting
>   fork() and file descriptor inheritance is supported.
>
> * The Ragel->C HTTP parser is taken from Mongrel.  This is the
>   only non-Ruby part and there are no plans to add any more
>   non-Ruby components.
>
> * All HTTP protocol parsing and I/O is done just like Mongrel:
>   1. read/parse HTTP request in full
>   2. call Rack application
>   3. write HTTP response back to the client
>
> * Like Mongrel, neither keepalive nor pipelining are supported.
>   These aren''t needed since Unicorn is only designed to serve
>   fast, low-latency clients directly.  Do one thing, do it well;
>   let nginx handle slow clients.
>
> * Configuration is purely in Ruby and eval().  Ruby is less
>   ambiguous than YAML and lets lambdas for before_fork/after_fork
>   hooks be defined inline.  An optional, separate hot_config_file
>   may be used to modify supported configuration changes
>   (and also gives you plenty of rope if you RTFS :>)
>
> * One master process spawns and reaps worker processes.  The
>   Rack application itself is called only within the worker process  
> (but
>   can be loaded within the master).  A copy-on-write friendly garbage
>   collector like Ruby Enterprise Edition can be used to minimize  
> memory
>   usage.
>
> * The number of worker processes should be scaled to the number of
>   CPUs, memory or even spindles you have.  If you have an existing
>   Mongrel cluster, using the same amount of processes should work.
>   Let a full-HTTP-request-buffering reverse proxy like nginx manage
>   concurrency to thousands of slow clients for you.  Unicorn scaling
>   should only be concerned about limits of your backend system(s).
>
> * Load balancing between worker processes is done by the OS kernel.
>   All workers share a common set of listener sockets and does
>   non-blocking accept() on them.  The kernel will decide which worker
>   process to give a socket to and workers will sleep if there is
>   nothing to accept().
>
> * Since non-blocking accept() is used, there can be a thundering
>   herd when an occasional client connects when application
>   *is not busy*.  The thundering herd problem should not affect
>   applications that are running all the time since worker processes
>   will only select()/accept() outside of the application dispatch.
>
> * Blocking I/O is used for clients.  This allows a simpler code path
>   to be followed within the Ruby interpreter and fewer syscalls.
>   Applications that use threads should continue to work if Unicorn
>   is serving LAN or localhost clients.
>
> * Timeout implementation is done via fchmod(2) in each worker
>   on a shared file descriptor to update st_ctime on the inode.
>   Master process wakeups for checking on timeouts is throttled
>   one a second to minimize the performance impact and simplify
>   the code path within the worker.  Neither futimes(2) nor
>   pwrite(2)/pread(2) are supported by base MRI, nor are they as
>   portable on UNIX systems as fchmod(2).
>
> * SIGKILL is used to terminate the timed-out workers as reliably
>   as possible on a UNIX system.
>
> * The poor performance of select() on large FD sets is avoided
>   as few file descriptors are used in each worker.
>   There should be no gain from moving to highly scalable but
>   unportable event notification solutions for watching few
>   file descriptors.
>
> * Since workers only work on one client at a time, the temporary
>   file for storing large POST/PUT requests is reused for the
>   lifetime of the process.  This should limit temp directory
>   growth on UNIX filesystems where temp file names are never
>   purged from the containing directory.
>
> * If the master process dies unexpectedly for any reason,
>   workers will notice within :timeout/2 seconds and follow
>   the master to its death.
>
> == License
>
> Unicorn is copyright 2009 Eric Wong and contributors.
> It is based on Mongrel:
>
> Mongrel is copyright 2007 Zed A. Shaw and contributors. It is licensed
> under the Ruby license and the GPL2. See the include LICENSE file for
> details.
>
> == Install
>
> The library consists of a C extension so you''ll need a C compiler
or
> at
> least a friend who can build it for you.
>
> Finally, the source includes a setup.rb for those who hate RubyGems.
>
> You can get the source via git via the following locations:
>
>  git://git.bogomips.org/unicorn.git
>
>  http://git.bogomips.org/unicorn.git
>
> == Usage
>
> See the Sinatra example.
>
> It should be capable of running all Rack applications.  Since this
> is a preforking webserver
>
> == Contact
>
> Newsgroup and mailing list coming, or it''ll be a part of the
Mongrel
> project...
>
> Email Eric Wong at normalperson at yhbt.net for now.
> ------------------------------- 8< ----------------------------
> _______________________________________________
> Mongrel-development mailing list
> Mongrel-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-development
Ezra Zygmuntowicz
ez at engineyard.com

Ryan Dahl <ry at tinyclouds.org> wrote:
> Eric,
> 
> this sounds great.
> 
> what would you think of adding an option to allow the server to
> connect to one (or more?) unix pipes for process restart instructions?
> i''d love to add a nginx module which notices when a backend is
> responding too slowly and can notify Unicorn to restart it. (this is
> the killer feature of passenger phusion.)
> 
> a simple protocol where a single byte message encodes the index of the
> backend that needs to be restarted would work i think (easy to
> multiplex with multiple writer processes)
Hi Ryan,

Something like this should already be doable via various means

Workers already process SIGQUIT to gracefully stop; so I''d rather not
reinvent that part even with a very simple protocol.

The master process already notices when timeout is expired and sends
SIGKILL to workers.  I could add a :soft_timeout config and have it send
SIGQUIT to workers if a lower timeout is reached.

On the other hand, I could see implementing soft_timeout having
statistics+heuristics, being URL/action-aware.  So IMHO this could be
more completely implemented as a separate package that watches the logs
via `tail -F`.  That way one can define which actions are allowed
to take longer without affecting the timeout (connecting to external
services for example).

As much as I love nginx, I''m really not a fan of adding modules and
increasing the complexity of the nginx process.  Yeah, I''m pretty
firmly on the "cat -v considered harmful" side of the fence :)

-- 
Eric Wong

> The master process already notices when timeout is expired and sends
> SIGKILL to workers.  I could add a :soft_timeout config and have it send
> SIGQUIT to workers if a lower timeout is reached.
yes - i just saw that. is that working well for you?
> Something like this should already be doable via various means
>
> Workers already process SIGQUIT to gracefully stop; so I''d rather
not
> reinvent that part even with a very simple protocol.
requires finding the pid of workers - but yes - that would work too

Ryan Dahl <ry at tinyclouds.org> wrote:
> > The master process already notices when timeout is expired and sends
> > SIGKILL to workers.  I could add a :soft_timeout config and have it
send
> > SIGQUIT to workers if a lower timeout is reached.
> 
> yes - i just saw that. is that working well for you?
It worked when I wrote it and added a sleep(120) to the bundled
"hello world" app; but haven''t had the chance to even use
run Unicorn today since I sent out the announcement email;
much less write proper tests for it.

-- 
Eric Wong

Hey, this is really interesting. I''ll investigate to see where
Mongrel2 and Unicorn are converging.

Let me know if you need more access to any Mongrel resources.

Evan

On Wed, Feb 11, 2009 at 7:28 PM, Eric Wong <normalperson at yhbt.net>
wrote:
> Ryan Dahl <ry at tinyclouds.org> wrote:
>> > The master process already notices when timeout is expired and
sends
>> > SIGKILL to workers.  I could add a :soft_timeout config and have
it send
>> > SIGQUIT to workers if a lower timeout is reached.
>>
>> yes - i just saw that. is that working well for you?
>
> It worked when I wrote it and added a sleep(120) to the bundled
> "hello world" app; but haven''t had the chance to even
use
> run Unicorn today since I sent out the announcement email;
> much less write proper tests for it.
>
> --
> Eric Wong
> _______________________________________________
> Mongrel-development mailing list
> Mongrel-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-development
>


-- 
Evan Weaver

Evan Weaver <evan at cloudbur.st> wrote:
> Hey, this is really interesting. I''ll investigate to see where
> Mongrel2 and Unicorn are converging.
I modified up some of the Http{Request,Response} stuff to be easier (at
least for me) to follow since I''m not worrying about Mongrel API
compatibility (and I don''t think Mongrel 2 is, either...).

Most of the cleanup changes are probably shareable with Mongrel except
for the blocking-I/O-dependent parts.

For Mongrel on UNIX, the multi-listener inheritance system of Unicorn
can definitely be added Mongrel.  Also, a Mongrel2 cluster could use
Unicorn-style process management + shared descriptors for load
balancing, but still use threads to service requests.

Eventually I may even make Unicorn to depend on Mongrel, but for now
I think having room to experiment and break stuff in isolation is
important for both projects to grow.

I''ve been trying to document most of my commits reasonably, feel free
to
ask if you have any questions about my changes and of course if you find
any bugs :)
> Let me know if you need more access to any Mongrel resources.
Is it OK if we continue using this mailing list for Unicorn discussion?

Can use the Mongrel Rubyforge account to do releases (eventually)?

Also, what''s happening with the current Mongrel Trac?  I''m not
a fan of
any web-based bug tracker/ticket systems, but maybe others are willing
to help out with maintaining that...

-- 
Eric Wong

Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
> This is really cool. I''m going to play with this now and see how
it
> works.
Hi Ezra, any news on your testing?

I''ve barely had a chance to work with it myself (I started writing this
email about 5 hours ago and got interrupted/distracted :x).
>From informal benchmarks on a purely CPU/memory-bound Sinatra app, when
simultaneous connections are less than nr_workers, Unicorn wins
slightly; however when there are more workers then the async I/O
buffering that Mongrel can do wins slightly over Unicorn.

Of course the app I tested with is atypical in that it:
  1) is completely thread-safe including all libraries used
  2) has no external dependencies outside of the machine it runs on
  3) has very uniform response times for all actions

Unicorn is of course designed for apps:
  1) with non-thread-safe dependencies
  2) that depend on (occasionally unreliable) external API calls
  3) where some actions taking measurably longer than others

Tests were run on a fairly unsaturated GigE LAN.

-- 
Eric Wong

Eric-


On Feb 16, 2009, at 3:39 PM, Eric Wong wrote:
> Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>> This is really cool. I''m going to play with this now and see
how it
>> works.
>
> Hi Ezra, any news on your testing?
>
> I''ve barely had a chance to work with it myself (I started writing
> this
> email about 5 hours ago and got interrupted/distracted :x).
>
>> From informal benchmarks on a purely CPU/memory-bound Sinatra app,  
>> when
> simultaneous connections are less than nr_workers, Unicorn wins
> slightly; however when there are more workers then the async I/O
> buffering that Mongrel can do wins slightly over Unicorn.
>
> Of course the app I tested with is atypical in that it:
>  1) is completely thread-safe including all libraries used
>  2) has no external dependencies outside of the machine it runs on
>  3) has very uniform response times for all actions
>
> Unicorn is of course designed for apps:
>  1) with non-thread-safe dependencies
>  2) that depend on (occasionally unreliable) external API calls
>  3) where some actions taking measurably longer than others
>
> Tests were run on a fairly unsaturated GigE LAN.
> mailman/listinfo/mongrel-development

	Seems to work as advertised so far, cool stuff ;) One suggestion,  
folks are pretty standardized on rack and config.ru files these days.  
I''d much rather see unicorn look for a APP_ROOT/config.ru to load as  
its config file rather then the eval that returns a hash style it uses  
now.

	Nice work.

Cheers-
Ezra Zygmuntowicz
ez at engineyard.com

Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
> 	Seems to work as advertised so far, cool stuff ;) One suggestion, folks 
> are pretty standardized on rack and config.ru files these days.
I''d much
> rather see unicorn look for a APP_ROOT/config.ru to load as its config 
> file rather then the eval that returns a hash style it uses now.
Ezra, thanks for testing and feedback.  Good point about config.ru,
I''ll try to make that change hopefully today to make it easier to
migrate from existing Rack apps.

-- 
Eric Wong

Eric Wong <normalperson at yhbt.net> wrote:
> Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
> > 	Seems to work as advertised so far, cool stuff ;) One suggestion,
folks
> > are pretty standardized on rack and config.ru files these days.
I''d much
> > rather see unicorn look for a APP_ROOT/config.ru to load as its config
> > file rather then the eval that returns a hash style it uses now.
> 
> Ezra, thanks for testing and feedback.  Good point about config.ru,
> I''ll try to make that change hopefully today to make it easier to
> migrate from existing Rack apps.
I just pushed out the following changes.

  * revamp configuration with Configurator DSL
  * Replace unicorn binary with something rackup-like
  * GNUMakefile: revamp for parallel 1.8/1.9 runs
  * test_exec: fix for temporary files not being cleaned
  * Fix+test reexec error handling on bad inputs

There''s also a few to http11 for general Rack compatibility
that should probably be merged for Mongrel 2.0:

  * http11: set SERVER_NAME env regardless of Host: header
  * http11: don''t bother defining SERVER_SOFTWARE
    (actually I think I only introduced this second one
    into Unicorn when I renamed the sources and stripped
    out a line)


Basically the latest push includes config.ru compatibility and new test
cases in test/exec/test_exec.rb for binary reexecution, listener
inheritance, and reloading config files (even bad ones).

This new config stuff is completely untested for any real apps and I''ll
need to update the examples soonish.  But the new test cases pass in
both 1.9.1 and 1.8.7, which is a good sign.

I think I''ll be writing more tests for various parts in the next few
days and avoiding major changes otherwise since I''m satisfied with
the existing feature set.

I also lack many real apps to test on atm since the production apps I
admin are still on various pre-Rack Rails versions[1].  So yeah, some
real world testing/feedback by you all would be greatly appreciated.


[1] Speaking of which, has anybody written a Rack app that wraps
    old Rails interfaces and makes them Rack-compatible yet?

-- 
Eric Wong

Eric Wong <normalperson at yhbt.net> wrote:
> Eric Wong <normalperson at yhbt.net> wrote:
> > Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
> > > 	Seems to work as advertised so far, cool stuff ;) One
suggestion, folks
> > > are pretty standardized on rack and config.ru files these days.
I''d much
> > > rather see unicorn look for a APP_ROOT/config.ru to load as its
config
> > > file rather then the eval that returns a hash style it uses now.
> > 
> > Ezra, thanks for testing and feedback.  Good point about config.ru,
> > I''ll try to make that change hopefully today to make it
easier to
> > migrate from existing Rack apps.
> 
> I just pushed out the following changes.
> 
>   * revamp configuration with Configurator DSL
>   * Replace unicorn binary with something rackup-like
>   * GNUMakefile: revamp for parallel 1.8/1.9 runs
>   * test_exec: fix for temporary files not being cleaned
>   * Fix+test reexec error handling on bad inputs
<snip>
> Basically the latest push includes config.ru compatibility and new test
> cases in test/exec/test_exec.rb for binary reexecution, listener
> inheritance, and reloading config files (even bad ones).
> 
> This new config stuff is completely untested for any real apps and
I''ll
> need to update the examples soonish.  But the new test cases pass in
> both 1.9.1 and 1.8.7, which is a good sign.
Help...

I''m basically a very confused person and I''m having trouble
deciding on
how/if config.ru should deal with the config file for Unicorn-specific
settings.  Or if the Unicorn-specific config file should be allowed to
specify/override config.ru...

Any ideas would be greatly appreciated, thanks!

-- 
Eric Wong

On Feb 23, 2009, at 5:03 PM, Eric Wong wrote:
> Eric Wong <normalperson at yhbt.net> wrote:
>> Eric Wong <normalperson at yhbt.net> wrote:
>>> Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>>>> 	Seems to work as advertised so far, cool stuff ;) One  
>>>> suggestion, folks
>>>> are pretty standardized on rack and config.ru files these days.
>>>> I''d much
>>>> rather see unicorn look for a APP_ROOT/config.ru to load as its
>>>> config
>>>> file rather then the eval that returns a hash style it uses
now.
>>>
>>> Ezra, thanks for testing and feedback.  Good point about config.ru,
>>> I''ll try to make that change hopefully today to make it
easier to
>>> migrate from existing Rack apps.
>>
>> I just pushed out the following changes.
>>
>>  * revamp configuration with Configurator DSL
>>  * Replace unicorn binary with something rackup-like
>>  * GNUMakefile: revamp for parallel 1.8/1.9 runs
>>  * test_exec: fix for temporary files not being cleaned
>>  * Fix+test reexec error handling on bad inputs
>
> <snip>
>
>> Basically the latest push includes config.ru compatibility and new  
>> test
>> cases in test/exec/test_exec.rb for binary reexecution, listener
>> inheritance, and reloading config files (even bad ones).
>>
>> This new config stuff is completely untested for any real apps and  
>> I''ll
>> need to update the examples soonish.  But the new test cases pass in
>> both 1.9.1 and 1.8.7, which is a good sign.
>
> Help...
>
> I''m basically a very confused person and I''m having
trouble deciding
> on
> how/if config.ru should deal with the config file for Unicorn-specific
> settings.  Or if the Unicorn-specific config file should be allowed to
> specify/override config.ru...
>
> Any ideas would be greatly appreciated, thanks!
>
> -- 
> Eric Wong

Eric-

	I''d say just make a small dsl or just  configuration object for  
unicorn options and let people use the dsl/object in their config.ru  
files.  Since config.ru is just ruby you can put any ruby code in  
there. Have folks put their unicron config code right at the top of  
config.ru. Will that work?

Cheers-
-Ezra

Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>
> On Feb 23, 2009, at 5:03 PM, Eric Wong wrote:
>
>> Eric Wong <normalperson at yhbt.net> wrote:
>>> Eric Wong <normalperson at yhbt.net> wrote:
>>>> Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>>>>> 	Seems to work as advertised so far, cool stuff ;) One  
>>>>> suggestion, folks
>>>>> are pretty standardized on rack and config.ru files these
days.
>>>>> I''d much
>>>>> rather see unicorn look for a APP_ROOT/config.ru to load as
its
>>>>> config
>>>>> file rather then the eval that returns a hash style it uses
now.
>>>>
>>>> Ezra, thanks for testing and feedback.  Good point about
config.ru,
>>>> I''ll try to make that change hopefully today to make
it easier to
>>>> migrate from existing Rack apps.
>>>
>>> I just pushed out the following changes.
>>>
>>>  * revamp configuration with Configurator DSL
>>>  * Replace unicorn binary with something rackup-like
>>>  * GNUMakefile: revamp for parallel 1.8/1.9 runs
>>>  * test_exec: fix for temporary files not being cleaned
>>>  * Fix+test reexec error handling on bad inputs
>>
>> <snip>
>>
>>> Basically the latest push includes config.ru compatibility and new
>>> test
>>> cases in test/exec/test_exec.rb for binary reexecution, listener
>>> inheritance, and reloading config files (even bad ones).
>>>
>>> This new config stuff is completely untested for any real apps and
>>> I''ll
>>> need to update the examples soonish.  But the new test cases pass
in
>>> both 1.9.1 and 1.8.7, which is a good sign.
>>
>> Help...
>>
>> I''m basically a very confused person and I''m having
trouble deciding
>> on
>> how/if config.ru should deal with the config file for Unicorn-specific
>> settings.  Or if the Unicorn-specific config file should be allowed to
>> specify/override config.ru...
>>
>> Any ideas would be greatly appreciated, thanks!
>
> Eric-
>
> 	I''d say just make a small dsl or just  configuration object for
unicorn
> options and let people use the dsl/object in their config.ru files.  
> Since config.ru is just ruby you can put any ruby code in there. Have 
> folks put their unicron config code right at the top of config.ru. Will 
> that work?
The new Unicorn::Configurator object is pretty much that DSL.

The main issue of handling config reloading (which should be "lighter"
than reexecuting the binary).  Should/could that re-eval() the
Rack::Builder bits?  How would I avoid that re-eval (without
dirtying the config up)[1].

Or should I handle reexecution as the only way to make config changes?
(I''ve strongly considered this, it''s a very big hammer :)

[1] - I don''t feel completly comfortable with Unicorn-specific stuff in
config.ru, in case it makes it harder for people to try out and compare
their app on Mongrel/Thin/Ebb/Passenger/Glassfish/whatever...  But I
suppose conditionals that check for defined?(Unicorn) can be enough...

-- 
Eric Wong

Eric Wong <normalperson at yhbt.net> wrote:
> Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
> > On Feb 23, 2009, at 5:03 PM, Eric Wong wrote:
> >> Eric Wong <normalperson at yhbt.net> wrote:
> >>> Eric Wong <normalperson at yhbt.net> wrote:
> >>>> Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
> >>>>> 	Seems to work as advertised so far, cool stuff ;) One
> >>>>> suggestion, folks
> >>>>> are pretty standardized on rack and config.ru files
these days.
> >>>>> I''d much
> >>>>> rather see unicorn look for a APP_ROOT/config.ru to
load as its
> >>>>> config
> >>>>> file rather then the eval that returns a hash style it
uses now.
> >>>>
> >>>> Ezra, thanks for testing and feedback.  Good point about
config.ru,
> >>>> I''ll try to make that change hopefully today to
make it easier to
> >>>> migrate from existing Rack apps.
> >>>
> >>> I just pushed out the following changes.
> >>>
> >>>  * revamp configuration with Configurator DSL
> >>>  * Replace unicorn binary with something rackup-like
> >>>  * GNUMakefile: revamp for parallel 1.8/1.9 runs
> >>>  * test_exec: fix for temporary files not being cleaned
> >>>  * Fix+test reexec error handling on bad inputs
> >>
> >> <snip>
> >>
> >>> Basically the latest push includes config.ru compatibility and
new
> >>> test
> >>> cases in test/exec/test_exec.rb for binary reexecution,
listener
> >>> inheritance, and reloading config files (even bad ones).
> >>>
> >>> This new config stuff is completely untested for any real apps
and
> >>> I''ll
> >>> need to update the examples soonish.  But the new test cases
pass in
> >>> both 1.9.1 and 1.8.7, which is a good sign.
> >>
> >> Help...
> >>
> >> I''m basically a very confused person and I''m
having trouble deciding
> >> on
> >> how/if config.ru should deal with the config file for
Unicorn-specific
> >> settings.  Or if the Unicorn-specific config file should be
allowed to
> >> specify/override config.ru...
> >>
> >> Any ideas would be greatly appreciated, thanks!
> >
> > Eric-
> >
> > 	I''d say just make a small dsl or just  configuration object
for unicorn
> > options and let people use the dsl/object in their config.ru files.  
> > Since config.ru is just ruby you can put any ruby code in there. Have 
> > folks put their unicron config code right at the top of config.ru.
Will
> > that work?
> 
> The new Unicorn::Configurator object is pretty much that DSL.
> 
> The main issue of handling config reloading (which should be
"lighter"
> than reexecuting the binary).  Should/could that re-eval() the
> Rack::Builder bits?  How would I avoid that re-eval (without
> dirtying the config up)[1].
> 
> Or should I handle reexecution as the only way to make config changes?
> (I''ve strongly considered this, it''s a very big hammer :)
> 
> [1] - I don''t feel completly comfortable with Unicorn-specific
stuff in
> config.ru, in case it makes it harder for people to try out and compare
> their app on Mongrel/Thin/Ebb/Passenger/Glassfish/whatever...  But I
> suppose conditionals that check for defined?(Unicorn) can be enough...
OK, here''s some thoughts leading up to what I''m probably going
to do...

 1. APP_ROOT/config.ru is in a pretty standardized location, good.

 2. Most config.ru files out there (probably) don''t contain
    environment-specific logic.  That is, developers on their
    desktop/laptops and the production app in datacenters can
    share the same config.ru without much difficulty.

    Can somebody please confirm this assumption?

 3. Unicorn-specific config options should only be needed for
    server deployments.  Things for the typical developer
    on their workstation should "just work", like running
    "script/server" and "mongrel_rails" in RAILS_ROOT does
    for old Rails apps.


This leads me to keeping the Unicorn config file separate for production
environments.  My personal experience (with old Rails apps) is that
there are multiple "production"-like environments (staging, QA,
different datacenters)...

I''d imagine some apps I support will end up with config file
layouts looking like this:

APP_ROOT/config/unicorn/prod_lax.rb
APP_ROOT/config/unicorn/prod_dfw.rb
APP_ROOT/config/unicorn/prod_nyc.rb
APP_ROOT/config/unicorn/prod_chi.rb
APP_ROOT/config/unicorn/qa.rb
APP_ROOT/config/unicorn/staging.rb
APP_ROOT/config/unicorn/demo.rb
APP_ROOT/config.ru

Thus to deploy to our Los Angeles datacenter, the script
would just run:

  unicorn -c APP_ROOT/config/unicorn/prod_lax.rb

If there''s an APP_ROOT/config_prod.ru needed, then
the APP_ROOT/config/prod_*.rb files would each
be able to specify APP_ROOT/config_prod.ru instead
of APP_ROOT/config.ru.

That is, the Unicorn config file can specify an alternate
config.ru, but config.ru cannot specify a different
Unicorn config file.

Am I making sense? (it''s been a long week for me so far...)

-- 
Eric Wong (no, I don''t have YHBT.net running in 4 locations, yet :)

> OK, here''s some thoughts leading up to what I''m probably
going
> to do...
>
> 1. APP_ROOT/config.ru is in a pretty standardized location, good.
>
> 2. Most config.ru files out there (probably) don''t contain
>    environment-specific logic.  That is, developers on their
>    desktop/laptops and the production app in datacenters can
>    share the same config.ru without much difficulty.
>
>    Can somebody please confirm this assumption?
Yeah i think APP_ROOT/config.ru is the standard here. Passenger uses  
it and its easy to use form rackup. heroku and ey-solo both look for  
config.ru in the approot.

>
> 3. Unicorn-specific config options should only be needed for
>    server deployments.  Things for the typical developer
>    on their workstation should "just work", like running
>    "script/server" and "mongrel_rails" in RAILS_ROOT
does
>    for old Rails apps.
Yeah I think this is a better idea then my suggestion.
>
>
> This leads me to keeping the Unicorn config file separate for  
> production
> environments.  My personal experience (with old Rails apps) is that
> there are multiple "production"-like environments (staging, QA,
> different datacenters)...
>
> I''d imagine some apps I support will end up with config file
> layouts looking like this:
>
> APP_ROOT/config/unicorn/prod_lax.rb
> APP_ROOT/config/unicorn/prod_dfw.rb
> APP_ROOT/config/unicorn/prod_nyc.rb
> APP_ROOT/config/unicorn/prod_chi.rb
> APP_ROOT/config/unicorn/qa.rb
> APP_ROOT/config/unicorn/staging.rb
> APP_ROOT/config/unicorn/demo.rb
> APP_ROOT/config.ru
>
> Thus to deploy to our Los Angeles datacenter, the script
> would just run:
>
>  unicorn -c APP_ROOT/config/unicorn/prod_lax.rb
>
> If there''s an APP_ROOT/config_prod.ru needed, then
> the APP_ROOT/config/prod_*.rb files would each
> be able to specify APP_ROOT/config_prod.ru instead
> of APP_ROOT/config.ru.
>
> That is, the Unicorn config file can specify an alternate
> config.ru, but config.ru cannot specify a different
> Unicorn config file.
>
> Am I making sense? (it''s been a long week for me so far...)
I think you''ve nailed it here.

Cheers-
Ezra