Re: [ANN] Thin v0.5.2 Cheezburger released

* [e-mail] ([e-mail]) wrote:

> The problem with this approach is really just that it's viability is
> an accident.  It's not described in any spec that I have ever seen on
> how Linux networks should behave.  It's not guaranteed to continue
> working, and there's no guarantee that it will continue to be
> implemented in a way that fairly distributes requests.

I'm quite sure that calling accept() on a filehandle shared across
processes is quite valid by POSIX, though it may not define it as having
to be safe to call concurrently.  If it isn't on your particular OS,
just:

  loop do
    if lockfile.flock(LOCK_EX)
      client = server.accept
      lockfile.flock(LOCK_UN)
      process(client)
    end
  end

If your OS can't support concurrent accept or make something like the
above work, it can't run, among many other things, Apache using any of
the Unix MPM's.  I don't know about you, but those OS's are not
interesting to me as deployment platforms, if at all.

Standards wise, with preforking and the proliferation of multithreaded
Ruby servers, and the introduction of Ruby 1.9 with native threading,
I'd be more concerned with people forking after spawning threads; POSIX
doesn't define the behavior of applications which call non async signal
safe functions in such an event, and it's actually known to cause
problems in systems people may actually like to use.

> So yes, on some platforms (Linux), it works, and has worked for quite
> a while.  But IMHO, using it for anything important is risky, and if
> one's app gets enough traffic that it needs a cluster,

You don't need much traffic to require a "cluster" (which I normally
associate with needing to scale out to multiple systems), you just need
a few slow running actions which can't run concurrently.  And if you do
need to scale out at short notice, it's probably nice to not have to
immediately run out and find an appropriate load balancer.

> it would seem to me that it's probably important enough to warrant
> using something that's actually designed to operate as a load balancer
> and that is guaranteed to be a load balancer in the future.

Load balancers are pretty poor for this sort of thing though; if you
have one server that's running slowly, most load balancers will still
quite happily hand off clients to it and be oblivious to them queuing up
waiting for it to actually accept().  After years of using these things,
there's what, one project to try to teach a single load balancer about
this sort of thing?

With multiple processes accepting off the same socket, even if one or
two are very busy, the queued up connections can be handed off to
another process; you could even dynamically spawn off and kill child
processes listening on the socket without having to mess about with port
allocations and load balancer configurations.

-- 
Thomas 'Freaky' Hurst
    http://hur.st/