[TransWarp] Pre-forking event-driven services

[Phillip J. Eby]

At 10:30 AM 8/15/03 -0400, Ty Sarna wrote:
>At 08:58 AM 8/15/03 -0400, Phillip J. Eby wrote:
> > [can't escape stupid mod_fastcgi bugs]
>
>Unless we use the style of FastCGI config we use with our legacy Zopes
>(FastCgiExternalServer), where mod_fastcgi doesn't do process management
>at all.
>
>The downside of this is that AFAIK, this *must* be configured in the
>main httpd.conf and not .htaccess files, like the other way can.

That's not the only downside, alas.  Another is that the process has to be 
started independently, via some mechanism that will handle retries in the 
event of failure (e.g. daemontools, or a URLChecker).  Otherwise, failure 
to start because of a database connection would stop the whole thing cold.

I suppose we live with these conditions right now for the legacy Zope 
applications, but that doesn't mean we want to have that situation for 
anything *else*.

A one-line patch to mod_fastcgi, however, would fix the "jealousy" bug.  I 
wonder if the maintainers would accept it?  Probably not, unless we added 
another inscrutable configuration option to control it.  ;)

To sum up: the two bugs (from our POV) in mod_fastcgi that we can't work 
around are:

1. If an application exits on its own initiative, even without an error 
condition, mod_fastcgi will restart it.  Thus, there is no way to have apps 
"wind down" on their own.

2. mod_fastcgi's measurements of load seem flawed: comments in its source 
code explicitly state that it's virtually impossible to get a "load" of 
higher than 0.5%, but you can only set threshholds at integer % 
levels...  So, if you use a non-zero threshhold, then processes are killed 
at every load check interval.  But if you use a zero threshhold, then the 
last process is never killed.

The combined effect of these two issues is that there's no way to configure 
mod_fastcgi to allow "no processes" to exist, unless you want it to kill 
the last process at every check interval!  If we could fix either one bug 
or the other, we'd be all set.  (At least, once we implemented the PEAK 
process manager.)

Maybe we can suggest to the mod_fastcgi maintainers that a clean 
application exit (i.e., without an error) be allowed to die in peace.  That 
would be the optimal solution for us, since then we can handle all process 
management in our own code, except for the start-on-demand, retry-on-error, 
and automatic socket allocation that mod_fastcgi's process manager provides.