Mailing List Archive

>
>
> Are there any other changes to the documentation on www.apache.org that
> we should do before the official release of 0.8 next week? I have
> Shambhala running on hyperreal now and have seen no problem with it -
> it's also on Organic, HotWired, and Links.net now, dishing up a million
> hits yesterday between all of us without a noticeable problem. I also
> wrote to the webmaster at playboy.com asking him if he'd consider
> switching to shambhala :)

Assuming we put the mod_imap in this release, I need to document some
of the addtions.


> RobT, if there's any release engineering you'd rather not do, let me know
> and I can finish it up. How does everyone feel about a monday morning
> release?

I am testing my changes to add the 'base_uri' field that RobT suggested.
I *may* get the changes in that Roy suggested, but since it is getting
down to the wire, it may be safer not to.


-Randy

> Hmmm... HotWired still calls itself Apache 0.6.1 when I ask, but it
> may be lying. (I hope so --- it would be nice to know it's been
> tested on Irix).

HotWired was running Shambhala all day Friday, with no problems
until it came time to stop the server and rotate the logs. One
of the local maintenance scripts broke at midnight, so I had to
fix things at 2 am. Since there were two things that had changed
recently (the script in question and the server), I put them both
back to what they had been earlier in the week and went to bed.

Yesterday I figured out it was the script and not Shambhala that
had problems, so I'll be swapping Shambhala back in when I get
into the office this afternoon.

Sean

Date: Sat, 15 Jul 1995 20:14:48 -0700 (PDT)
From: Brian Behlendorf <brian@organic.com>

Are there any other changes to the documentation on www.apache.org that
we should do before the official release of 0.8 next week?

It would be nice to update the VirtualHost docs to indicate that you
can now stick other httpd.conf and srm.conf commands in there, in
addition to those explicitly listed in the current documentation.
Mkgray's new logging modules are undocumented, as is Randy's imagemap
module (I presume we'll want to release with both of those). There's
also 'TransferLog "| ..."', but given all the caveats on it, the best
thing may be to leave that undocumented for the moment. API docs are
still incomplete, but I'm resigned to that at this point.

I have
Shambhala running on hyperreal now and have seen no problem with it -
it's also on Organic, HotWired,

Hmmm... HotWired still calls itself Apache 0.6.1 when I ask, but it
may be lying. (I hope so --- it would be nice to know it's been
tested on Irix).

and Links.net now, dishing up a million
hits yesterday between all of us without a noticeable problem. I also
wrote to the webmaster at playboy.com asking him if he'd consider
switching to shambhala :)

Well, I've listed below what's in my current development sandbox.
This stuff all passes smoke tests at least, and I'm running with it on
my main server --- it includes several bug fixes, and one new feature
(adapting the number of server processes to ongoing activity) which
*seems*, at least to be working nicely. I should have a new snapshot
with all of this stuff (also mkgray's logging modules and, if you're
lucky, at least a crude config script) by this evening.

(The hairiest of these changes is the scoreboard-based regulation of
the number of active servers. I'm a bit antsy about this, but it's
already tested and seems to work well, and the code should be *very*
portable --- the most obscure thing it uses is mktemp()).

RobT, if there's any release engineering you'd rather not do, let me know
and I can finish it up. How does everyone feel about a monday morning
release?

Hmmm... the stuff that has to be done at this point is mostly
packaging, but even packaging needs time to be done right (and at
least a little testing --- at the level of unpacking it somewhere
other than where it was built, and doing enough with it to determine
that no essential pieces were omitted).

As for things I'd rather *not* do --- there are two; building a *full*
distribution (which actually should involve nothing more than taking
0.[67].x and replacing the 'src' directory), and also, perhaps,
switching the license text everyplace to something with a disclaimer
paragraph which has been looked over by a Real Lawyer (such as the
Berkeley license text included below); that second one would
presumably have to at least be run up the flagpole to see if anyone
objects, though I sincerely doubt anyone would. If you want to do
that, feel free...

rst

PS --- the attachments: work completed in my sandbox [.this should
be it for changes to server code, barring new modules and further bugfixes].

*) Scoreboard mechanism for regulating the number of extant server
processes. MaxServers and StartServers defaults are the same as
for NCSA, but the meanings are slightly different.

Before asking for a new connection, each server process checks
the number of other servers which are also waiting for a
connection. If there are more than MaxServers, it quietly dies
off. Conversely, every second, the root, or caretaker, process
looks to see how many servers are waiting for a new connection;
if there are fewer than StartServers, it starts a new one. This
does not depend on the number of server processes already extant.
The accounting is arranged through a "scoreboard" file, named
/tmp/htstatus.*, on which each process has an independant file
descriptor (they need to seek without interference).

The end effect is that MaxServers is the maximum number of
servers on an *inactive* server machine, but more will be forked
off to handle unusually heavy loads (or unusually slow clients);
these will die off when they are no longer needed --- without
reverting to the overhead of full forking operation. There is a
hard maximum of 150 server processes compiled in, largely to
avoid forking out of control and dragging the machine down.
(This is arguably too high).

In my server endurance tests, this mechanism did not appear to
impose any significant overhead, even after I forced it to put the
scoreboard file on a normal filesystem (which might have more
overhead than tmpfs).

*) Set HTTP_FOO variables for SSI <!--#exec cmd-->s, not just CGI scripts.
[Bug reported by Cliff Skolnick]

*) Read .htaccess files even in directory with <Directory> section.
(Former incompatibility noted on mailing list, now fixed).

*) "HEAD /" gives the client a "Bad Request" error message, rather
than trying to send no body *and* no headers. [Cliff again].

*) Don't produce double error reports for some very obscure cases
mainly involving auth configuration (the "all modules decline to
handle" case which is a sure sign of a server bug in most cases,
but also happens when authentication is badly misconfigured).

*) Moved FCNTL_SERIALIZED_ACCEPT defines into conf.h (that's what
it's *for*, and this sort of thing really shouldn't be cluttering
up the Makefile).

*) Incidental code cleanups in http_main.c --- stop dragging
sa_client around; just declare it where used.

*) Another acc-related fix from Mark Cox. (It doesn't like const char
in some places...).

Berkeley warranty disclaimer (note all caps):

# THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.