From: Eric Wong <normalperson@...>
Date: 2009-12-12T16:11:22+09:00
Subject: Re: Unicorn Server questions

Mr Balla <blarg@sogetthis.com> wrote:
> First is regarding the the "listen" configuration option. Why is this
> option important? What can I do once a worker is set up to listen on a
> port? I do not really see the need of this unless....

Hi,

You mean a per-worker listen for workers (inside after_fork hooks)?
It's entirely optional in that case but may be useful for debugging or
migrating from another server.  Normally you start a listen socket in
the master process and that is automatically shared when it forks off
workers.

By default, if you specify any listen, it will listen on TCP port 8080.

> What I am really trying to do is check each worker processes backlog and
> if it exceeds some arbitrary number I can tell my load balancer to mark
> that machine down. Is this even possible? From within in Rails (or
> anyway) is there a way for me to check on the current state of Unicorn?

The listen backlog is managed entirely by the kernel.  There may be
instrumentation packages for your kernel that make it possible to
inspect the backlog, but off the top of my head I don't know of any (nor
have I ever needed it).

Keep in mind that the exact size of the backlog is rarely exactly the
value you specified.

> Can you please point me in the right direction as I am having problems
> finding any good information on these topics.

A good chunk of Unicorn configuration options map directly to the
underlying UNIX system calls, so reading UNIX/Linux manpages is a good
way to understand Unicorn:

The following manpages are a good start:

  socket(7), tcp(7), unix(7) - overall concepts

  listen(2), fork(2), setsockopt(2), socket(2), ... actual syscalls

-- 
Eric Wong