NetWare mod_dav import file, WAS: Re: svn commit: r160636 - httpd/httpd/trunk/modules/dav/main/dav.imp
[EMAIL PROTECTED] wrote: Author: bnicholes Date: Fri Apr 8 16:03:45 2005 New Revision: 160636 URL: http://svn.apache.org/viewcvs?view=revrev=160636 Log: Update the mod_dav import file for NetWare I assume something similar has to be done for 2.0.x? Sander
NetWare Builds and Apache 2.0-dev
Greetings All, In recent times the NetWare build files for Apache 2.1 were modified to support APR and APR-Util in locations other than http\srclib, a worthy advance given the current discussion to break out separate libraries. At the present time however, the Apache 2.0-dev trunk no longer provides APR and APR-Util below .\srclib (they are obtained separately), yet the build files for NetWare in Apache 2.0 still assume that is where the two libraries are located. Given that the vast majority of NetWare users _don't_ build it, would it be possible to update the 2.0 trunk NWGNU* files to work the same as for Apache 2.1? I suspect that 2.1 has already been built often enough with its current build system that it could safely be 'backported' to 2.0. Regards, Norm
Re: NetWare Builds and Apache 2.0-dev
At 05:46 AM 4/10/2005, NormW wrote: At the present time however, the Apache 2.0-dev trunk no longer provides APR and APR-Util below .\srclib (they are obtained separately), yet the build files for NetWare in Apache 2.0 still assume that is where the two libraries are located. They certainly should be present. It was never the intent to divorce apr/apr-util distribution from httpd-2.0 (although that CERTAINLY is the goal for httpd-2.2). Can you point at exactly what .tar.gz you are looking at? Bill
mod_version for 2.0.x, was Re: svn commit: r160645 - httpd/httpd/branches/2.0.x/STATUS
Paul Querna wrote: Okay, I was backporting this, but ran into a few problems. First, it requires a minor MMN bump to add the version API stuff. Thats not too bad, and I was making a patch for all of it. The biggest problem is that my working copy in subversion broke. 'svn diff' just doesn't work right (added files are not shown). I opened a bug report on it: http://subversion.tigris.org/issues/show_bug.cgi?id=2270 I am ready to give up on mod_version for 2.0.54 unless someone else is feeling lucky.. Since the subversion people think that my 'expectations' of 'svn diff' working this way are wrong, I turned it into an integration branch: https://svn.apache.org/repos/asf/httpd/httpd/branches/mod_version_for_2.0.x I believe everything needed is done in that branch. Source Code (Including a Minor MMN Bump!), Build System and Documentation. Because this backport has grown quite large, I reset the voting in the STATUS file -- I think people were mostly agreeing on the concept. Personally, I didn't see the need of a minor MMN bump until I did the backport. -Paul
Re: NetWare Builds and Apache 2.0-dev
Good morning Bill, Thanks for the pick-up. My mention of 2.0-dev refers to 2.0 trunk, and as such, it doesn't come in a tar.gz until after it is fully packaged as a tagged entity. In CVS days fetching 2.0 from CVS also got APR and APR-Util in their 'final' locations, so that building 2.0 was straight forward. With the change to SVN, the APR files are downloaded as separate modules and now logically exist at the same 'level' as 2.0 httpd itself. 2.1 bit the bullet and its NetWare build files were revised so that they work regardless of wether it's a build from trunk or a tagged package; just asking if the same feature might not be extended to 2.0? Anyone building NetWare from source shouldn't be 'thrown' too far by a documented need to create two extra memvars. Regards, Norm William A. Rowe, Jr. wrote: At 05:46 AM 4/10/2005, NormW wrote: At the present time however, the Apache 2.0-dev trunk no longer provides APR and APR-Util below .\srclib (they are obtained separately), yet the build files for NetWare in Apache 2.0 still assume that is where the two libraries are located. They certainly should be present. It was never the intent to divorce apr/apr-util distribution from httpd-2.0 (although that CERTAINLY is the goal for httpd-2.2). Can you point at exactly what .tar.gz you are looking at? Bill .
Re: NetWare Builds and Apache 2.0-dev
CVS checkout never 'deposited' the apr or apr-util trees into the httpd-2.0/srclib/ tree. It was up to whatever checkout script you used to do so. There really isn't a change with svn, other than command syntax. One thing worth bringing up - I don't -want- to see us link the checkouts. I've had numerous problems with cvs and svn when we try to tie the trees in the cvs/svn steps. Just look at the mechanical mess left in modperl/ApacheTest etc trying to check out an historical tag. One trick has always been (at least under cvs) - to remove the entities for D/apr etc. If you tried to update by tag, and those directories could be traversed from your httpd-2.0 root, it would potentially grab tags invalid for the apr CVS tree. The same is possibly true for svn. In any case, I never actually check out apr in my working trees into srclib, but toss a symlink there, instead. If you see a tarball for a 2.0.5x candidate (a release tarball) submitted for approval, without apr/apr-util, feel free to ask for a new tarball with the RM's choice of apr 0.9.x etc. Bill At 04:02 PM 4/10/2005, NormW wrote: Good morning Bill, Thanks for the pick-up. My mention of 2.0-dev refers to 2.0 trunk, and as such, it doesn't come in a tar.gz until after it is fully packaged as a tagged entity. In CVS days fetching 2.0 from CVS also got APR and APR-Util in their 'final' locations, so that building 2.0 was straight forward. With the change to SVN, the APR files are downloaded as separate modules and now logically exist at the same 'level' as 2.0 httpd itself. 2.1 bit the bullet and its NetWare build files were revised so that they work regardless of wether it's a build from trunk or a tagged package; just asking if the same feature might not be extended to 2.0? Anyone building NetWare from source shouldn't be 'thrown' too far by a documented need to create two extra memvars. Regards, Norm William A. Rowe, Jr. wrote: At 05:46 AM 4/10/2005, NormW wrote: At the present time however, the Apache 2.0-dev trunk no longer provides APR and APR-Util below .\srclib (they are obtained separately), yet the build files for NetWare in Apache 2.0 still assume that is where the two libraries are located. They certainly should be present. It was never the intent to divorce apr/apr-util distribution from httpd-2.0 (although that CERTAINLY is the goal for httpd-2.2). Can you point at exactly what .tar.gz you are looking at? Bill .
[PATCH] Have buildconf support out-of-tree APR and APU
Folks,
I would like to keep my checkout layout like so:
httpd/
/trunk
apr/
/apr
/trunk
/apr-util
/trunk
So, I would like to call from the httpd checkout ./buildconf
--with-apr=../../apr/apr/trunk --with-apr-util=../../apr/apr-util/trunk
The following patch should fully propagate these parameters:
Index: buildconf
===
--- buildconf (revision 160800)
+++ buildconf (working copy)
@@ -127,23 +127,19 @@
cross_compile_warning=warning: AC_TRY_RUN called without default to
allow cross compiling
-if [ -d srclib/apr ]; then
-echo rebuilding $apr_configure
-(cd srclib/apr ./buildconf) || {
-echo ./buildconf failed for apr
-exit 1
-}
-rm -f srclib/apr/apr.spec
-fi
+echo rebuilding $apr_configure
+(cd ${apr_src_dir} ./buildconf) || {
+echo ./buildconf failed for apr
+exit 1
+}
+rm -f ${apr_src_dir}/apr.spec
-if [ -d srclib/apr-util ]; then
-echo rebuilding $aprutil_configure
-(cd srclib/apr-util ./buildconf) || {
-echo ./buildconf failed for apr-util
-exit 1
-}
-rm -f srclib/apr-util/apr-util.spec
-fi
+echo rebuilding $aprutil_configure
+(cd ${apu_src_dir} ./buildconf --with-apr=${apr_src_dir}) || {
+echo ./buildconf failed for apr-util
+exit 1
+}
+rm -f ${apu_src_dir}/apr-util.spec
echo copying build files
cp $apr_src_dir/build/config.guess $apr_src_dir/build/config.sub \
This allows buildconf to complete as invoked above. I basically
propagate the ap{r,u}_src_dir variable through the script, and into
${apu_src_dir}/buildconf. I'm also removing the directory checks, since
they have been done before and the script has failed already if they
don't exist.
Next up: hack the httpd configure script (or its input) to learn from
buildconf about AP{R,U}. I'd like to post this first though to gather
input.
Thoughts?
S.
--
[EMAIL PROTECTED] http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
smime.p7s
Description: S/MIME cryptographic signature
Apache 2.0.53 + Firefox 1.0.1 - incomplete downloads?
Just wondering if -anyone- else has been seeing this; Using the download mgr to grab .iso's from mirrors (anl.gov) using Apache 2.0.53. My MD5 sums seem to be batting 50%, although download speed and behavior is quite acceptable. I'm wondering if trailing/last packet data might be prone to issues, due to pipelining, keepalives, or whatnot. This is especially odd as the Download manager reports % of all files - counting 'done' files, meaning firefox might not believe it's 100% complete. If nobody else is seeing this, I'll assume I'm hallucinating and that it's specific to my config or this mirror. Otherwise I'll investigate further. Bill
Re: [PATCH] Have buildconf support out-of-tree APR and APU
At 05:11 PM 4/10/2005, Sander Temme wrote:
I would like to keep my checkout layout like so:
httpd/
/trunk
apr/
/apr
/trunk
/apr-util
/trunk
So, I would like to call from the httpd checkout ./buildconf
--with-apr=../../apr/apr/trunk --with-apr-util=../../apr/apr-util/trunk
Thoughts?
This brings to mind a recent kludgy commit. Really, to take this
to the logical extreme (and greatest flexibility) - I'd entertain
not only this patch, but a patch which created ./buildconf.nice
for remembering the locations of our dependencies.
Some commented before that it's overkill, but they hacked in their
preferred layout, and your post proves that there is no 'one true
right layout' that works for everyone.
My own schema?
builds/httpd-2.0
/srclib/{symlinks to...}
builds/apr-0.9/
builds/apr-util-0.9/
repeat for httpd-1.3 (no dependency on apr) and httpd-2.1 dependent
on apr-1.1 and apr-util-1.1
Bill
keepalivetimeout and 2.2 configs
While the 2.2 config files are somewhat in flux, I thought I'd bring up the topic of KeepAliveTimeout. The default config files have this set to 15 seconds. As far as I remember, it is set that way due to some possibly-scientific survey that said that average web users click ever 15 seconds. Even assuming that that was true at some point, it seems to me that the main reason for keepalive is for the files (images, css) associated with a single page, not for retaining a connection between pages. In that case, I would think that 2, or perhaps 3 seconds, would be more than sufficient. On the more practical non-gut-feeling side, I've found consistently that changing KeepAliveTimeout from 15 to 3 immediately, and drastically, reduces server load on busy servers, where a significant percentage of the child processes are in Keepalive mode most of the time. See http://httpd.apache.org/server-status for an example. Note that (most of the time) most of the processes are in K. I'm willing to bet that reducing KeepAliveTimeout to 2 or 3 will drop the number of child processes significantly, reduce overall server load, and improve server performance under peak traffic. Thoughts? --Rich
Re: keepalivetimeout and 2.2 configs
On Sun, 10 Apr 2005, Rich Bowen wrote: While the 2.2 config files are somewhat in flux, I thought I'd bring up the topic of KeepAliveTimeout. The default config files have this set to 15 seconds. As far as I remember, it is set that way due to some possibly-scientific survey that said that average web users click ever 15 seconds. Even assuming that that was true at some point, it seems to me that the main reason for keepalive is for the files (images, css) associated with a single page, not for retaining a connection between pages. In that case, I would think that 2, or perhaps 3 seconds, would be more than sufficient. On the more practical non-gut-feeling side, I've found consistently that changing KeepAliveTimeout from 15 to 3 immediately, and drastically, reduces server load on busy servers, where a significant percentage of the child processes are in Keepalive mode most of the time. See http://httpd.apache.org/server-status for an example. Note that (most of the time) most of the processes are in K. I'm willing to bet that reducing KeepAliveTimeout to 2 or 3 will drop the number of child processes significantly, reduce overall server load, and improve server performance under peak traffic. I tend to agree that 15 is too high for prefork, but a couple notes: - It's always a trade-off between the memory used by the idle worker and the performance cost of setting up and tearing down connections. Different sites care about those resources to different degrees. - This is highly mpm-dependent. For threaded mpms, the cost of an idle worker is lower. For the new event mpm, the problem goes away entirely, and you are better off with a much *higher* timeout. So pushing event up the list of recommended mpms would be the best way to solve this. It would be nice if other mpms were a little more flexible about KeepAlive policy, like by lowering the timeout when you get near MaxClients. - If you make KeepAlive less available, you encourage client authors to setup more connections to the server, which will cost way more. - This should be solved in the code-default, not the config-file default. The directive will not exist in the default config file in 2.1.next. - 2-3 seconds seems too short for modem or high-latency connections. 5-10 seems more in the ballpark. Joshua.
Re: keepalivetimeout and 2.2 configs
On Sun, 10 Apr 2005, Rich Bowen wrote: See http://httpd.apache.org/server-status for an example. Note that (most of the time) most of the processes are in K. I'm willing to bet that reducing KeepAliveTimeout to 2 or 3 will drop the number of child processes significantly, reduce overall server load, and improve server performance under peak traffic. Oh, and by the way, I don't really agree with this. KeepAliveTimeout on www.apache.org is currently 5. Reducing it would only help performance if we are hitting MaxClients. And since we don't have a memory problem, if we are hitting MaxClients we should be raising MaxClients, not reducing KeepAliveTimeout. Connections in KeepAlive aren't using any resources except memory, so messing with this only helps memory-constrained servers (which, admittedly, are not uncommon). Joshua.
[patch] cache_util.c
Adjust time unit and typo.
Tsuyoshi SASAMOTO
[EMAIL PROTECTED]
--- httpd/trunk/modules/cache/cache_util.c Mon Apr 11 11:00:00 2005
+++ httpd/trunk/modules/cache/cache_util.c Mon Apr 11 11:00:00 2005
@@ -272,7 +272,7 @@
if (!(((smaxage != -1) age smaxage) ||
((maxage != -1) age maxage) ||
(info-expire != APR_DATE_BAD
- (info-expire - info-date) age))) {
+ apr_time_sec(info-expire - info-date) age))) {
/* make sure we don't stomp on a previous warning */
if ((warn_head == NULL) ||
((warn_head != NULL) (ap_strstr_c(warn_head, 110) ==
NULL))) {
@@ -289,7 +289,7 @@
(expstr == NULL) (age 86400)) {
/* Make sure we don't stomp on a previous warning, and don't dup
- * a 113 marning that is already present. Also, make sure to add
+ * a 113 warning that is already present. Also, make sure to add
* the new warning to the correct *headers_out location.
*/
if ((warn_head == NULL) ||
