librelist archives

Shutdown and Reloading Refactoring

From:

Zed A. Shaw

Date:

2011-04-08 @ 16:39

Just a quick message to say trunk is a little broken right now while I
refactor handler reloading and shutdown.  Reloading now works much more
reliably, but shutdown doesn't work because zmq_term doesn't honor the
ZMQ_LINGER setting properly.  I may just say screw it and have mongrel2
full on exit, which kind of sucks.

How the shutdown code has changed is all of the backends (handlers,
proxies, dirs) are put into one tst structure and tracked universally
there.  They're put in based on a long full string that represents their
database record and type.  When a reload happens, the config.c code now
just zips through all backends and marks them as "running = 0".  Then
when the config is loaded again, any handlers that are duplicate are
flipped back to running = 1.

What this means is handlers that are new get created, handlers that
haven't changed just keep running (since they're stateless), and dead
handlers will exit after they handle one more message.

This also makes it easy for the control port to list handlers and other
information.  It also cleaned up the config.c code considerably which
will make the "use any damn thing you want" config method I'm planning
easier.

But, until I solve the zmq_term not really terminating problem it'll
have shutdown issues.  Stay tuned for that fix.

-- 
Zed A. Shaw
http://zedshaw.com/

What do you mean by 'exit'?  Are you killing off the handler process when 
it's corresponding handler config is removed from config.sqlite?

✈ Matt



On Apr 8, 2011, at 09:39 , Zed A. Shaw wrote:

> What this means is handlers that are new get created, handlers that
> haven't changed just keep running (since they're stateless), and dead
> handlers will exit after they handle one more message.

On Fri, Apr 08, 2011 at 09:47:36AM -0700, Matt Towers wrote:
> What do you mean by 'exit'?  Are you killing off the handler process
> when it's corresponding handler config is removed from config.sqlite?

Nope, handler processes are outside mongrel2's domain.  I mean the
little internal coroutine.  Inside the handler processing code there's a
loop like this:

while(handler->running) {
    // do handler stuff
}

// clean up and exit


That way, if you have a handler, and it changed config, it'll exit once
it goes through the loop again.  If it didn't change then it'll keep
running and work the same since they're stateless.  If it's a new
handler then it just fires up a coroutine for it and lets it run.

Works really well with the test you sent me, except for a few edge cases
for proxies and dirs.  Try it out and let me know what you get, but
don't put it in production.

-- 
Zed A. Shaw
http://zedshaw.com/

Will do.

✈ Matt



On Apr 8, 2011, at 15:44 , Zed A. Shaw wrote:

> Works really well with the test you sent me, except for a few edge cases
> for proxies and dirs.  Try it out and let me know what you get, but
> don't put it in production.