On Mon, 30 Jul 2001, GUMMALAM,MOHAN (HP-Cupertino,ex2) wrote:
> It still exhibits the same problem as was evident in 2.0.19 and later
> releases, there is only 1 process up and running, (apart from the cgid and
> the watchdog process).
>
> This is a bug - a bad implementation of the lo-watermark and hi-watermark
> logic, and makes Apache web-server 2.0.22 not enterprise quality. Justin's
> patch of two mutexes did fix the problem, but I do not see it being included
> even now.
This is the only seriously negative feedback I've gotten so far on 2.0.22.
If it's true, then it's a problem, yes, but what are people's feelings
about its severity? I personally don't consider it a showstopper, though
it's worth a cautionary note in the announcement... something along the
lines of the note below. Thoughts?
Here is the current list of known issues. Have I missed anything?
--Cliff
--------------------------------------------------------------
Known issues with 2.0.22:
1) Win9x and WinME do not yet work correctly
2) There are a few known issues with the threaded MPM, including some
problems during graceful restarts and a discrepancy between the number
of running workers and the number configured. A revamp of the threaded
MPM that should fix these problems is currently under development.
3) mod_dav fails to compile as a DSO if you use --enable-mods-shared=all
or --enable-shared=most. It has been reported that using
--enable-dav=shared --enable-dav_fs=shared explicitly works around
the problem.
4) mod_auth_dbm, mod_auth_db, and mod_auth_digest might not compile on
some systems due to missing headers or libraries which are not
correctly flagged as missing by configure. A workaround is to
rerun configure, explicitly disabling the offending module using
--disable-auth-dbm, --disable-auth-db, or --disable-auth-digest.
5) mod_ssl is still in the process of being ported to Apache 2.0 and
should be considered alpha quality at best. It might not work or
even compile on all systems and not all functionality is currently
enabled.
6) The config.guess included in the tarball does not correctly
recognize Mac OS X/Darwin. A workaround for this is to replace
all copies of config.guess in the tarball with a newer copy from
ftp://ftp.gnu.org/gnu/config/
7) srclib/apr/threadproc/unix/signals.c fails to link on Mac OS X/Darwin
due to unresolved symbols. This can be worked around with the
following patch (which should only be used on OS X):
--- srclib/apr/threadproc/unix/signals.c~ Mon Jul 30 13:13:47 2001
+++ srclib/apr/threadproc/unix/signals.c Mon Jul 30 13:11:15 2001
@@ -330,6 +330,7 @@
/* All threads should mask signals out, according to sigwait(2) man
page */
sigfillset(&sig_mask);
+#define SIGPROCMASK_SETS_THREAD_MASK 1
#if defined(SIGPROCMASK_SETS_THREAD_MASK)
rv = sigprocmask(SIG_SETMASK, &sig_mask, NULL);
#else
--------------------------------------------------------------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
