This patch fixes a nasty bug in the worker MPM where the
state of the worker threads was not being reported back to the
scoreboard, and eventually all the threads running in the children
would be reported as being in the "C -- closing connection" state.
This would wreak havoc on the idle_server_maintenance() routine. Since
these threads would never be counted as idle, the server would
spawn children as fast as possible.
Switch back to SIGUSR1 for graceful restarts on all platforms that
support it. This defines a symbol called AP_SIG_GRACEFUL in
ap_config_auto.h which will have the appropriate signal value. All
direct references to SIGWINCH have been replaced with AP_SIG_GRACEFUL.
On Linux 2.0, use SIGWINCH instead since SIGUSR1 is used by glibc
2.0's user-space threading library to control threads. All later
versions of Linux/glibc don't have this problem. (Not to mention the
security holes in older Linux versions which make it unsuitable for
use as a web server.) If your platform doesn't have SIGUSR1, use the
appropriate mojo in configure to define what your graceful restart
signal should be.
In theory, a configure switch could be added to allow the admin to
specify the appropriate signal that should be used. This is left
as an exercise to the reader for now.
The docs need to be updated. Since the signal is now configurable,
just saying SIGUSR1 for graceful restart isn't completely true. Also,
the apachectl functionality needs to be moved into httpd - this is
what Win32 does and it makes us consistent across platforms.
Roy issued a veto against use of SIGWINCH by default, so this should
resolve that veto.
Ryan Bloom [Tue, 18 Sep 2001 21:14:18 +0000 (21:14 +0000)]
Cleanup the worker MPM. We no longer re-use transaction
pools. This incurs less overhead than shuffling the pools
around so that they can be re-used. Remove one of the
queue's condition variables. We just redefined the API to
state that you can't try to add more stuff than you allocated
segments for.
Revamp the API that mod_dav uses to talk to back end deadprop (propdb)
providers. The old API was really based on how the FS stored properties, but
sucked for other types of providers (SQL databases, Subversion, etc). This
new code is overall much cleaner as it moves from a DBM style API to one
tuned for actual mod_dav operation; it also more flexible/clearer for future
improvements (e.g. dropping props directly to the wire rather than buffering
in memory).
This new API allows the provider to better define namespace handling during
the output of the values, how values are serialized and stored, the mapping
between elements' namespaces and the internalized namespace storage, a
clearer mechanism for naming properties (dav_prop_name), and an explicit
rollback mechanism to deal with PROPPATCH atomicity.
Updated the FS provider (fs/dbm.c) to the new API, mostly by moving code
from main/props.c. Of course, with the new semantics, some big changes in
the namespace mapping were made.
Now that we have apr_datum_t, convert some uses of dav_datum over to
apr_datum_t (the two are equivalent).
Expose some of the DAVFS' internal DBM cover functions and have the locking
code use them directly, rather than thru the vtable. That vtable will be
changing shortly, so this shift is needed.
Remove the Win32 script-processing exception from mod_cgi, and
roll build_command_line/build_argv_list into a unified, overrideable
ap_cgi_build_command optional function.
Eliminates a ton of Win32 cruft from core.c for registry parsing.
Win32 (through the default handler, and newest changes to the
apr_proc_create fn) continues to serve .bat/.exe files. This is in
preparation for adding modules/arch/win32/mod_win32 for scripts.
Please review the mod_cgi.c behavior very carefully.
Temporary hack to ensure that the split results are within a brigade
attached to the proper pool. Otherwise, ctx->b would end up associated with
the request pool, and the SOCKET bucket from the CORE_IN filter would get
cleared at request end (thus the next request would go to CORE_IN for more
data and get APR_EOF, and figured there were no more requests).
This section of code was only triggered when a request had a body. The
symptom was closing the connection (even though it should have been a
keepalive) after the response was sent.
For more info, see Message-ID on dev@: <20010917061613.B466@lyra.org>
Found the persistent connection problem I've been observing. Nasty result of
the problems in the input filter stack. Time to rejigger, per the
discussions we've had.
Ryan Bloom [Wed, 12 Sep 2001 19:50:56 +0000 (19:50 +0000)]
Remove mod_tls. All of the filters in mod_tls can now be found in
mod_ssl. Also, mod_ssl is being kept up to date, while mod_tls is not,
so that if you use mod_tls, there are a lot of bugs, both security related,
and otherwise.
Ryan Bloom [Tue, 11 Sep 2001 18:38:21 +0000 (18:38 +0000)]
A very small optimization to the OLD_WRITE logic. This just makes us store
a pointer to the OLD_WRITE frec, and instead of using strcmp or strcasecmp,
we can just do a simple pointer comparison. This optimization is also
available to other modules.
Bill Stoddard [Mon, 10 Sep 2001 18:09:56 +0000 (18:09 +0000)]
Introduce the notion of a multi part cache object. Part of the cache_object
is common across any cache implementation, the other part is private to
the particular implementation (eg, mem_cache_object_t/mod_mem_cache).
Use a cache_handle_t allocated out of the request pool to hold references
to the callback functions and common cache object.
The cache_handle_t contains implementation specific callback functions and
a reference to a common cache_object_t. The cache_object_t contains
a reference to an implementation specific cache object extension (mem_cache_object_t
for example).
All this simplifies managing the callback function pointers (don't want to
save them in each cache entry) and collections of cache_object_t keyed
to a single url.
Ryan Bloom [Mon, 10 Sep 2001 13:45:12 +0000 (13:45 +0000)]
It is completely bogus that I feel I have to do this. I remain -1 for
doing this, but I won't veto it. I am 100% with JimJ on this. We are
making this decision at the wrong time, and for the wrong reasons. I
do not believe that this module ever belongs in the core, and I haven't
heard a single valid reason for using it. Even the SSL reason has been
removed in my mind, due to the fact that we are now thinking of
removing mod_gz if the correct cipher is used, because the correct cipher
will compress for us.
This patch is insufficient (highlights an existing problem) for OS2 and
Netware, especially, and any other platform with odd native requirements
for the PATH_TRANSLATED variable (where it should look like a filesystem
entity for non-unixish cgi's.)
The per_dir_merge overlay of AddInputFilter/AddOutputFilter must
absolutely replace a prior definition for the same file extension.
Picture AddOutputFilter Includes .html in a directory, and needing
to replace that behavior in a subdirectory which does not contain
SSI html files. This behavior must remain consistent to the other
mime behaviors, as documented in manual/mod/mod_mime.html
Ryan Bloom [Sat, 8 Sep 2001 01:10:29 +0000 (01:10 +0000)]
The threaded MPM not working is not because of httpd or APR. Threads
are horribly broken on FreeBSD, and there is nothing we can do to fix
them. Unless, of course, somebody wants to contribute code to the
FreeBSD project.
Jeff Trawick [Fri, 7 Sep 2001 14:01:26 +0000 (14:01 +0000)]
We finally got APR working well enough to support buffered reading
of .var files, so the .var file issue is gone.
The brokenness of the threaded MPM on FreeBSD is a FreeBSD issue, not
an Apache issue, as far as anyone can tell. I don't think this should
be in the STATUS file at all, unless somebody thinks we should issue a
big honking warning from configure if somebody tries to enable threaded.
Optimize location_walk. We build an array of incremental matches, and
on attempting a subreq/redirect or simply a second pass, and for each
match in series, if the section is a match, we reuse the merge result
for that section.
Ryan Bloom [Thu, 6 Sep 2001 15:04:01 +0000 (15:04 +0000)]
I am veto'ing this, for now at least. I will support making mod_gz
a separate sub-project of httpd, and possibly rolling it into a later
release of 2.0, but now is not the time to do this.
I didn't crawl the list looking for the complete set of votes, but here we
go. Nominally, this issue would be under "lazy approval" since no changes
are made to APIs, directives, or significant size changes in the runtime.
However, the nature of the discussions effectively calls for "consensus
approval" -- three binding +1 votes and no vetoes.