Re: [patch] perchild MPM bug fixes (+ open problem)
Johannes Erdfelt [EMAIL PROTECTED] writes: I spent some time debugging the perchild MPM since it wasn't working for me, nor anyone else it seems. I've found a few problems: just FYI so you don't feel ignored... if nobody beats me to it, I plan to take a more detailed look at this with the intent to commit... nag me directly in a few days if I haven't found the time to play with it now... no need to rework this now, but patches that are smaller and solve exactly one problem at a time get committed sooner... -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: [PATCH] Win32: Why explicitly futz with the file pointer?
At 08:33 PM 10/19/2002, Bill Stoddard wrote: Why do we need to call SetFilePointer to each call of apr_file_write()? In the common case where only threads in a single process write to a file, calling SetFilePointer is a waste of cycles. If threads from multiple processes are writing to a file, then we are broken unless the application explicitly serializes access to apr_file_write() The code predates my involvement in apr, however... don't you suppose the question belongs in the devapr list?
Re: [PATCH]: Counting I/O with FLUSH
Sorry to be a pest (no, not really :-)... Would this patch have more chance if it didn't involve an MMN bump? If so, let me know and I'll rework it... Bojan
Re: [Vote] 2.1 fork near ready?
On Sun, Oct 20, 2002 at 03:58:00PM -0700, Justin Erenkrantz wrote: --On Sunday, October 20, 2002 3:20 PM -0700 Aaron Bannert [EMAIL PROTECTED] wrote: I think this whole RTC vs. CTR debate is moot at this point. We all trust each other not to mess up the repositories too much, and we all hold code-level veto power over any commit (with technical justification). Given that, I see no reason to put arbitrary roadblocks in front of our trusted committers. Even with the best of intentions, people can unknowningly break the tree. It happens - we're human. By enforcing a policy that mandates prior peer review, we would ensure the integrity of the stable tree to the best of our ability. Exactly. CVS commit emails are good enough peer review for me. One of OtherBill's stated goals was to ensure a level of stability at all times in the stable tree. Unless we follow RTC rules, I don't believe we can guarantee that stability. I don't believe any complex piece of software in the world can ever make such a definately guarantee, and surely by reading the Apache License one would get the impression that the ASF does not make those kinds of claims as a matter of policy. All we can say is that this release is probably more stable (and has been in our own subjective opinion) than the last. The difference between branches marked stable and development is not the same as it probably works and it probably doesn't work. The difference is in how we as committers feel about what kinds of changes are appropriate to make in each repository. I believe that only bug fixes belong in the stable tree, while feature additions belong in the development branch. I'm not suggesting RTC on the -development tree - the guarantee of stability isn't there, but I believe it is on -stable. We should enforce a policy that reflects our desire of stability. -- justin I'm saying -1 to RTC ever in any openly democratic and strongly peer-reviewed ASF project. -aaron p.s. I don't consider this to be a vetoable choice, -1 just reflects my opposition. :)
multiple host headers?
Just playing around ;-) Consider the following request: (test is a directory) GET /test HTTP/1.1 Host: gsmpf Host: test Host: lala HTTP/1.1 301 Moved Permanently Date: Mon, 21 Oct 2002 00:27:17 GMT Server: Apache/2.0.43 (Win32) Location: http://gsmpf, test, lala/test/ Content-Length: 314 Content-Type: text/html; charset=iso-8859-1 [...] hmm. RFC 2616/4.2 says: | Multiple message-header fields with the same field-name MAY be | present in a message if and only if the entire field-value for that | header field is defined as a comma-separated list [i.e., #(values)]. 'Host:' isn't defined as #(values) in any way (see 14.23). So the response should be a simple 400 Bad Request, shouldn't it? nd -- Die Untergeschosse der Sempergalerie bleiben währenddessen aus statistischen Gründen geflutet. -- Spiegel Online
Re: Why initial location walk?
* William A. Rowe, Jr. wrote: [a lot of explanations about location walks] I'll trace it in the source these days, thanks a lot! (and will ask further if neccessary ;-) nd -- s;.*;aoaaaoaaoaaaom:a:alataa:aaoat:a:a:a maoaa:a:laoata:a:oia:a:o:a:m:a:o:alaoooat:aaool:aaoaa matooololaaatoto:aaa:o:a:o:m;;s:\s:\::g;y;mailto:; \40\51/\134\137|ndparker [EMAIL PROTECTED];;print;
RE: distributing encryption software
Please tell me if I'm missing something here: when I tried to volunteer to give apache binaries for HP-UX (around 6 - 8 months ago), I got back a response that only the committers can produce the binaries. Is somebody thinking of relaxing this restriction? -Madhu -Original Message- From: Jeff Trawick [mailto:trawick;attglobal.net] Sent: Saturday, October 19, 2002 10:32 AM To: [EMAIL PROTECTED] Subject: Re: distributing encryption software Pier Fumagalli [EMAIL PROTECTED] writes: On 19/10/02 14:35, Jeff Trawick [EMAIL PROTECTED] wrote: I can't install Solaris 8 from a recent enough CD-ROM set that has sendfile if I want to do Apache 2.0 binbuilds which are usable by the general Solaris 8 user community (you can't even download sendfile+prerequisites without a maintenance contract last time I tried). Hmm... You can download the latest version of Solaris, boot from the CD, and for PACKAGE in `pkginfo -r /a` ; do pkginst -r /a /Products/$PACKAGE ; done (expand the obvious bits where the stuff wouldn't work)... Basically you're going to replace the whole OS with a new one, or you can just replace a couple of packages (SUNWcor and SUNWcorx)... Ok, it's a hack, but what the heck! :-) but that isn't something that somebody wants to do to a production server just so they can pick up a security fix; and if it is one of the many people for which doing their own build of Apache is non-trivial, they should be hesitant to do that anyway Heck, even with Win32 there aren't many people who can do binbuilds, and that is particularly bad when a security fix is announced and everybody looks for the same one person. And given that MSVC costs $, the problem gets bigger... yep; and just look at the price of Sun's or HP's or IBM's compiler If there were money (thanks for downloading the latest Apache binary distribution for your platform; would you care to contribute a few euros towards the generation and availability of what you just downloaded?), it would be possible to maintain a set of machines running the appropriate set of system software to enable binbuilds to be reliably built for the largest possible audience. If a loosely affiliated group (unencumbered friends of Apache) could accept contributions and maintain a rich set of binbuilds of Apache with/without SSL support, a lot of users would be happier and a lot of PRs could be closed with less hair turning gray but without breaking the user (I'm sorry you are encountering this particular build SNAFU. It works fine for a number of people on that platform. There is a trusted binary build for your platform available from www.xx.org.). More than what you were interested I'm sure, but there are other frustrating aspects of binbuilds than just the encryption issue. Well, I don't think that you need $$$, the only thing you really need is hardware (for the builds), bandwidth (for downloads) and time (to build)... and software... vendor compilers can cost much more than a used, older generation hardware box but depending on the platform they get along with libtool better and/or generate significantly better code than the free compilers point well taken, but money can ease the life of the volunteers... sure, you can put help, the drive on our HP-UX build machine died... can anybody send us one? but it is much more efficient for volunteers to have a slush fund that will buy exactly the right new drive in a heartbeat rather than wait for some unknown individual to send in something... sure, volunteers can go nag all their contacts for a free copy of a Microsoft compiler or an AIX box or whatever, but with so many people (particularly Win32-ers), making use of binary builds, it seems that with small contributions from some of them a better product could be provided --/-- My view is that we could provide a much better binbuild service than we do today, and that it is reasonable to ask for contributions to cover the real costs so that the volunteers only have to worry about preparing the consistent set of binbuilds when there is a new release instead of wasting their time haranguing their friends and other contacts trying to scrounge up this vendor compiler or that piece of hardware. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
RE: distributing encryption software
Please tell me if I'm missing something here: when I tried to volunteer to give apache binaries for HP-UX (around 6 - 8 months ago), I got back a response that only the committers can produce the binaries. As far as I know and understand only committers can put them in the official binary directory. And the committers only take binaries they made themselves - for security/trust reasons. But of course everyone is free to produce binaries and put them on some web page, perhaps they get in some contrib directory on the apache server too and perhaps you get a nice link from some page - but those aren't official binaries then. Correct me if i'm wrong.. j. -- The man who does not read good books has no advantage over the man who cannot read them. -- Mark Twain - http://jgcl.at/ko/ - new photos from summer camp 2002 in Moosen/Tirol
Re: [Vote] 2.1 fork near ready?
--On Sunday, October 20, 2002 3:20 PM -0700 Aaron Bannert [EMAIL PROTECTED] wrote: I think this whole RTC vs. CTR debate is moot at this point. We all trust each other not to mess up the repositories too much, and we all hold code-level veto power over any commit (with technical justification). Given that, I see no reason to put arbitrary roadblocks in front of our trusted committers. Even with the best of intentions, people can unknowningly break the tree. It happens - we're human. By enforcing a policy that mandates prior peer review, we would ensure the integrity of the stable tree to the best of our ability. One of OtherBill's stated goals was to ensure a level of stability at all times in the stable tree. Unless we follow RTC rules, I don't believe we can guarantee that stability. I'm not suggesting RTC on the -development tree - the guarantee of stability isn't there, but I believe it is on -stable. We should enforce a policy that reflects our desire of stability. -- justin
[PATCH] Fix for bug #7617: race condition causes 3 second CGI delay
When running my newly installed apache 2.0.40 on my RedHat 8.0 linux box, I noticed some strange 3-second delays for clients using keepalives after running CGI scripts before the next request was processed. Some debugging led me to the conclusion that I experienced the same race-condition as described as #7616 in the bug database. I.e. after running the CGI script, apache finds the subprocess to still be active, sends it a SIGINT and then blocks for three whole seconds before sending a SIGKILL. Meanwhile, the client using keep-alives is kept waiting for those three seconds until the next request is processed. What a waste of time, considering the CGI script actually exited almost immediately after the SIGINT was sent. I confirmed this same behaviour to be present in version 2.0.43, and saw the need to make a fix to this. Apache 1.3.27 has very similar code, so the same patch could be easily modified to work with that version as well! Please find enclosed a patch against the 2.0.40 source tree (should work well on 2.0.43 also) that fixes this unnecessary delay. The patch makes apache check the status of the subprocesses in 0.1 second intervals, until either a total of three seconds have elapsed or all subprocesses have exited. Any subprocesses still running after 3 seconds are then SIGKILLed as before. Hope this quick fix can make it into the official version! Best regards, Kai -- [EMAIL PROTECTED] Oy Arrak Software Ab GSM +358-40-767 8282http://www.arrak.fi httpd-2.0.40-subprocess.patch Description: Binary data
Re: Prefork MPM Question
Thanks for the reply.
See my inline comments
--
On Fri, 18 Oct 2002 13:11:23
gregames wrote:
amit athavale wrote:
I am using Apache 2.0 with prefork MPM. There is some external program which adds
VirtualHosts to httpd.conf dynamically and send SIGUSR1 to a process with pid = {pid
in httpd.pid}. Immediately after this, that external program sends some HTTP request
which should resolve to new VirtualHost added. (These are WebDAV requests to create
some default resources and set properties)
But unfortunately, these requests go to old processes(before restarting). Is there
any way to ensure that these requests go to new processes ?
There could be a graceful restart bug (we did have one in prefork months ago),
or it might be that the graceful restart notification simply hasn't had time to
propagate to all the child processes.
I would take a close look at server-status with ExtendedStatus enabled, before
and right after you send the signal. For each child pid that's alive, you
should see either a new generation number in the Srv column or a G (gracefully
finishing) in the M column. When we had the bug, you would see processes with
the old generation number serving new requests for hours after the graceful
restart was initiated.
Will do that and let you know.
But I added some loging, so that when request comes PID is printed, and some request
shows old PID.
Interestingly if I fire MaxClients no. of requests these old processes goes away.
If that looks OK, maybe your external program just needs to sleep for a few
seconds after initiating the graceful restart.
This external program sleeps for 20 secs after giving signal.
If the server-status looks bad,
which platform are you on and what level of httpd are you running?
I am on Solaris 8 and unfortunately using 1st GA release of 2.0 i.e 2.0.35. May be the
bug you are refering to was there 2.0.35, is this right ? if so then I need to patch
my source with fix.
Greg
Get 250 full-color business cards FREE right now!
http://businesscards.lycos.com
