Hi,
I'm working with the same stack and problem that Alec has been
describing here. I have a new (but still vague) theory about what's
happening for your consideration. In trying to understand exactly how
the daemon process restart mechanism works, I noticed that the switch
statement in wsgi_manage_process() has no default block. There's at
least one documented 'reason' code which is not handled:
APR_OC_REASON_UNWRITABLE. I'm not exactly sure what that code means,
but I was able to reproduce the problem (declining number of daemon
children) by adding these lines to the top of wsgi_manage_process():
if (daemon->process.pid % 2) {
reason = APR_OC_REASON_UNWRITABLE;
}
This is admittedly contrived, but demonstrates that the problem
*could* be related to an unexpected condition (unhandled reason) or
error (transient resource shortage) occurring during the execution of
wsgi_manage_process(). There seems to be at most one opportunity to
get the terminating daemon restarted. If there was a
wsgi_stork_thread() similar to wsgi_reaper_thread(), then perhaps the
restart could be retried later in the event of transient difficulties.
-Ben
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en.
