[mod_python] strange behavior with mpm worker (inaccurate number of max processes?)

> Just ignore it if it seems wrong. It is quite possible mod_python does
> it wrong

Am I correct in thinking that this bug will actually reduce the number of
available maxclients to mod_python (i.e. it's not just a logging error)?
We serve both scripts and static content from this apache server, so
hopefully this will at least not affect the settings for static content?

Incidentally, I think this random number "11 max processes" is the actual
number of processes that were alive when apache was restarted by cron. Since
we run that cron at night, the number of processes that we need during the
day is higher, so this could be a problem.

> -----Original Message-----
> From: Graham Dumpleton [mailto:graham.dumpleton at gmail.com]
> Sent: Monday, January 21, 2008 7:38 PM
> To: Alec Matusis
> Cc: mod_python at modpython.org
> Subject: Re: [mod_python] strange behavior with mpm worker (inaccurate
> number of max processes?)
> 
> Just ignore it if it seems wrong. It is quite possible mod_python does
> it wrong, or does it in a way which isn't compatible with newer
> versions of Apache. The code certainly has various warnings against
> the code which make it look a little suspect.
> 
>     /* figure out maximum possible concurrent connections */
>     /* MAX_DAEMON_USED seems to account for MaxClients, as opposed to
>        MAX_DAEMONS, which is ServerLimit
>     */
>     ap_mpm_query(AP_MPMQ_IS_THREADED, &is_threaded);
>     if (is_threaded != AP_MPMQ_NOT_SUPPORTED) {
>         ap_mpm_query(AP_MPMQ_MAX_THREADS, &max_threads);
>     }
>     ap_mpm_query(AP_MPMQ_IS_FORKED, &is_forked);
>     if (is_forked != AP_MPMQ_NOT_SUPPORTED) {
>         /* XXX This looks strange, and it is. prefork.c seems to use
>            MAX_DAEMON_USED the same way that worker.c uses
>            MAX_DAEMONS (prefork is wrong IMO) */
>         ap_mpm_query(AP_MPMQ_MAX_DAEMON_USED, &max_procs);
>         if (max_procs == -1) {
>             ap_mpm_query(AP_MPMQ_MAX_DAEMONS, &max_procs);
>         }
>     }
>     max_clients = (((max_threads <= 0) ? 1 : max_threads) *
>                    ((max_procs <= 0) ? 1 : max_procs));
> 
> Graham
> 
> On 21/01/2008, Alec Matusis <matusis at yahoo.com> wrote:
> >
> >
> >
> >
> > We are using worker MPM
> >
> > Our apache configuration is
> >
> >
> >
> > ServerLimit 40
> >
> > ThreadLimit 70
> >
> >
> >
> > StartServers          10
> >
> > MaxClients            1600
> >
> > MinSpareThreads       75
> >
> > MaxSpareThreads       200
> >
> > ThreadsPerChild       40
> >
> > MaxRequestsPerChild   10000
> >
> >
> >
> > When apache is restarted with
> >
> > #apachectl stop
> >
> > #apachectl start
> >
> > We get in the error log:
> >
> > [notice] mod_python: Creating 32 session mutexes based on 40 max
> processes
> > and 40 max threads
> >
> > [notice] Apache/2.2.6 (Unix) mod_python/3.3.1 Python/2.4.1 configured
> --
> > resuming normal operations
> >
> > This is what we expect.
> >
> >
> >
> > Now we restart apache this way:
> >
> > #apachectl restart
> >
> > In the error log:
> >
> > [notice] SIGHUP received.  Attempting to restart
> >
> >  [notice] mod_python: Creating 32 session mutexes based on 11 max
> processes
> > and 40 max threads.
> >
> >  [notice] mod_python: using mutex_directory /tmp
> >
> >  [notice] Apache/2.2.6 (Unix) mod_python/3.3.1 Python/2.4.1
> configured --
> > resuming normal operations
> >
> >
> >
> > Where does this number "11 max processes" come from? We do not have
> it
> > anywhere in the configuration.
> >
> >
> >
> >
> >
> > We get
> >
> >
> > _______________________________________________
> > Mod_python mailing list
> > Mod_python at modpython.org
> > http://mailman.modpython.org/mailman/listinfo/mod_python
> >
> >