Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfigPerl.pm
Doug MacEachern wrote:
On Sun, 16 Sep 2001, Stas wrote:
Hmm, we don't want to pass the package name to the package itself
why not?
because we know the package name anyway inside that package. :)
this fixes it, so we can write:
sub APACHE_TEST_CONFIG {
my $self = shift;
this seems fine to me:
my($class, $config) = @_;
and what's the user of $class? When you can access it via __PACKAGE__
and you don't really need it anyway.
-eval { $module-APACHE_TEST_CONFIGURE($self); };
+no strict 'refs';
+eval { ${module}::APACHE_TEST_CONFIGURE-($self) };
this way passes use strict:
my $cv = \{${module}::APACHE_TEST_CONFIGURE};
eval { $cv-($self) };
I think this is even better, as can is already returning a ref to a sub
if found.
if (my $cv = $module-can('APACHE_TEST_CONFIGURE')) {
eval { $cv-($self) };
warn $@ if $@;
}
but i think the current way in cvs is correct.
true, it's correct. I just didn't want to add any data to the API, that you
will never use.
--
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Tag time?
Not that I volunteer to be RM or anything, but any reason why we couldn't try to get a beta out this week? -- justin
[lists-openbsd@bsws.de: [donotreply@Apache.Org: Re: OpenBSD + Apache as heavy loaded webserver and the cgi problem]]
(Working through antique misfiled mail) Not acked. - Forwarded message from Henning Brauer [EMAIL PROTECTED] - From: Henning Brauer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [[EMAIL PROTECTED]: Re: OpenBSD + Apache as heavy loaded webserver and the cgi problem] Date: Mon, 15 Jan 2001 04:23:46 +0100 User-Agent: Mutt/1.2.5i may fit on your performance tuning page... From: Henning Brauer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: OpenBSD + Apache as heavy loaded webserver and the cgi problem Date: Mon, 15 Jan 2001 03:37:17 +0100 Hi all, a while ago I sent some apache header file modifications to run under heavy load on OpenBSD. Unfortunately the original problem came up again, the server was unable to start CGI's. I found a solution now: in /usr/src/sys/sys/syslimits.h, change: #define CHILD_MAX 512 #define OPEN_MAX 512 (defining them as option in kernel config does NOT work!) in your kernel config: maxusers 512 option NMBCLUSTERS=8192 option NKMEMCLUSTERS=8192 option MAX_KMAP=120 option MAX_KMAPENT=6000 in apache's httpd.h: #define HARD_SERVER_LIMIT 2048 and, after recompiling, adjust the parameters in your apache config file, especially MaxClients, MaxSpareServers, MinSpareServers and the Keepalive stuff. Note that starting new apache processes is expensive, so don't set the startservers and spareservers stuff too low. The optimal values may differ depending on your load. Whenever you see error messages like couldn't spawn child process the values for CHILD_MAX and OPEN_MAX could be your problem. Also play with FD_SETSIZE in apache's ap_config.h, I'm still figuring out the optimal value for my setup. Greetings Henning -- Henning Brauer | BS Web Services Hostmaster BSWS| Roedingsmarkt 14 [EMAIL PROTECTED] | 20459 Hamburg http://www.bsws.de | Germany - End forwarded message - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: Tag time?
On Sun, 16 Sep 2001, Justin Erenkrantz wrote: Not that I volunteer to be RM or anything, but any reason why we couldn't try to get a beta out this week? -- justin I was going to send out a message yesterday asking what the remaining showstoppers were. Did we ever track down that segv that surfaced when using mod_php and then others? I need to go back and find that email where an example of a troublesome config was given. What other problems are out there? It'd be nice to wrap up this buckets alloc thing before a new tag since it involves API changes, but I guess it's not a showstopper. --Cliff PS: I volunteered to RM 2.0.26 a while back and am still willing... -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: cvs commit: httpd-2.0/server mpm_common.c
This is gross - can we please abstract into apr (preferrably in some
automated manner?)
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, September 14, 2001 6:28 PM
Subject: cvs commit: httpd-2.0/server mpm_common.c
bnicholes01/09/14 16:28:41
Modified:server mpm_common.c
Log:
Added NetWare to the #ifdef list
Revision ChangesPath
1.66 +1 -1 httpd-2.0/server/mpm_common.c
Index: mpm_common.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm_common.c,v
retrieving revision 1.65
retrieving revision 1.66
diff -u -r1.65 -r1.66
--- mpm_common.c 2001/08/16 13:59:14 1.65
+++ mpm_common.c 2001/09/14 23:28:41 1.66
@@ -326,7 +326,7 @@
#ifndef HAVE_INITGROUPS
int initgroups(const char *name, gid_t basegid)
{
-#if defined(QNX) || defined(MPE) || defined(BEOS) || defined(_OSD_POSIX) ||
defined(TPF) || defined(__TANDEM) || defined(OS2)
|| defined(WIN32)
+#if defined(QNX) || defined(MPE) || defined(BEOS) || defined(_OSD_POSIX) ||
defined(TPF) || defined(__TANDEM) || defined(OS2)
|| defined(WIN32) || defined(NETWARE)
/* QNX, MPE and BeOS do not appear to support supplementary groups. */
return 0;
#else /* ndef QNX */
Re: Apache-1.3: question about mod_unique_id
From: Greg Stein [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 7:36 PM Subject: Re: Apache-1.3: question about mod_unique_id On Windows, for 1.3, you can simply call CoCreateGuid() and be done with it. And the Windows guids are unique. Probably doesn't make too much sense for 1.3 - it breaks 95. [ I seem to recall this thread started as a result of a Windows problem; UUIDs would solve it for that platform. maybe it was Netware? ] Actually, all threaded servers, I count 4-5 flavors. Regarding APR's UUID solution: if you think it isn't good enough, then I'd be interested in knowing. It collects a decent amount of see and then hashes it to get a random result. If there is more seed data that we could use, then we should. This seems very worthwhile across platforms for 2.0 ;) From: Greg Stein [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 7:39 PM For *Windows*, why bother? Use a UUID. You *know* it is unique. For other platforms, the discussion could be longer, but I don't understand why you would want to tie yourself in a knot when CoCreateGuid() is just calling out to solve this. To avoid three different solutions for something noone wants to spend the time on? Solve it once for all for 1.3 - and be done with that code branch :-)
Re: Apache-1.3: question about mod_unique_id
From: Brad Nicholes [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 4:06 PM I checked with our CLIB people and they tell me that GetThreadID is *not* unique. In other words, if a thread is created, it is assigned an ID. If that thread is terminated and a new thread is created, the new thread may reuse the ID from the terminated thread. That's fine, neither is GetProcessID. The point is, the timer is ticking while the requests fly. I expect time+proc+thread+randomization is sufficent.
Re: [PATCH] Relative server root...
Take the argv[0] through apr_filepath_merge(server_root, , argv[0], 0, global_pool) so that we assure that the systemwide path is canonical, and I'm +1 Bill - Original Message - From: Brad Nicholes [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 3:55 PM Subject: [PATCH] Relative server root... I would like to propose the following code changes for main.c. These changes will allow a platform to use a relative server root that is based on argv[0] rather than a hard coded server root. If these changes seem fair, I would like to check them in. thanks, Brad
Re: Tag time?
On Sunday 16 September 2001 01:34 pm, Justin Erenkrantz wrote: Yes, the code isn't ready. There is at least one seg fault that we already know about. Ryan Not that I volunteer to be RM or anything, but any reason why we couldn't try to get a beta out this week? -- justin -- __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: Tag time?
On Sun, Sep 16, 2001 at 04:46:08PM -0400, Cliff Woolley wrote: On Sun, 16 Sep 2001, Justin Erenkrantz wrote: Not that I volunteer to be RM or anything, but any reason why we couldn't try to get a beta out this week? -- justin I was going to send out a message yesterday asking what the remaining showstoppers were. Did we ever track down that segv that surfaced when using mod_php and then others? I need to go back and find that email where an example of a troublesome config was given. What other problems are out there? It'd be nice to wrap up this buckets alloc thing before a new tag since it involves API changes, but I guess it's not a showstopper. Apache's prefork MPM seems to be having problems with persistent connections. They've been dogging some of my testing and SVN. I'm gonna dig into it this evening. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: Tag time?
On Sun, Sep 16, 2001 at 01:49:12PM -0700, Ian Holsman wrote: On Sun, 2001-09-16 at 13:34, Justin Erenkrantz wrote: Not that I volunteer to be RM or anything, but any reason why we couldn't try to get a beta out this week? -- justin Aaron also has some worker MPM patches I'm benchmarking at the moment. Although I'd like to get the best worker MPM implementation into CVS as soon as possible, I don't consider this a beta showstopper (at least as long as worker isn't the default MPM on UNIX). -aaron
[PATCH 2] Remove notes table
I missed a couple of files (notably mod_rewrite.c) in the original patch.
Here is an updated version.
--Brian
Index: include/httpd.h
===
RCS file: /home/cvspublic/httpd-2.0/include/httpd.h,v
retrieving revision 1.165
diff -u -r1.165 httpd.h
--- include/httpd.h 2001/09/14 23:30:41 1.165
+++ include/httpd.h 2001/09/16 23:42:13
@@ -733,9 +733,6 @@
* The difference between headers_out and err_headers_out is that the
* latter are printed even on error, and persist across internal redirects
* (so the headers printed for ErrorDocument handlers will have them).
- *
- * The 'notes' apr_table_t is for notes from one module to another, with no
- * other set purpose in mind...
*/
/** MIME header environment from the request */
@@ -747,8 +744,6 @@
apr_table_t *err_headers_out;
/** Array of environment variables to be used for sub processes */
apr_table_t *subprocess_env;
-/** Notes from one module to another */
-apr_table_t *notes;
/* content_type, handler, content_encoding, content_language, and all
* content_languages MUST be lowercased strings. They may be pointers
Index: modules/dav/main/mod_dav.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/dav/main/mod_dav.c,v
retrieving revision 1.60
diff -u -r1.60 mod_dav.c
--- modules/dav/main/mod_dav.c 2001/08/23 19:00:07 1.60
+++ modules/dav/main/mod_dav.c 2001/09/16 23:42:16
@@ -526,7 +526,7 @@
if (response == NULL) {
/* our error messages are safe; tell Apache this */
- apr_table_setn(r-notes, verbose-error-to, *);
+ apr_pool_userdata_set(*, verbose-error-to, NULL, r-pool);
return err-status;
}
Index: modules/generators/mod_cgi.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/generators/mod_cgi.c,v
retrieving revision 1.103
diff -u -r1.103 mod_cgi.c
--- modules/generators/mod_cgi.c2001/08/27 20:25:42 1.103
+++ modules/generators/mod_cgi.c2001/09/16 23:42:17
@@ -122,8 +122,10 @@
static int is_scriptaliased(request_rec *r)
{
-const char *t = apr_table_get(r-notes, alias-forced-type);
-return t (!strcasecmp(t, cgi-script));
+const char *t;
+return (apr_pool_userdata_get((void **)t, alias-forced-type,
+ r-pool) == APR_SUCCESS)
+ t (!strcasecmp(t, cgi-script));
}
/* Configuration stuff */
Index: modules/http/http_protocol.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/http/http_protocol.c,v
retrieving revision 1.361
diff -u -r1.361 http_protocol.c
--- modules/http/http_protocol.c2001/09/02 03:21:47 1.361
+++ modules/http/http_protocol.c2001/09/16 23:42:19
@@ -1626,7 +1626,8 @@
{
const char *notes, *result;
-if ((notes = apr_table_get(r-notes, key)) == NULL) {
+if ((apr_pool_userdata_get((void**)notes, key, r-pool) != APR_SUCCESS)
+|| !notes) {
result = apr_pstrcat(r-pool, prefix, suffix, NULL);
}
else {
@@ -1818,8 +1819,12 @@
* that is totally safe for any user to see (ie lacks paths,
* database passwords, etc.)
*/
- if (((error_notes = apr_table_get(r-notes, error-notes)) != NULL)
-(h1 = apr_table_get(r-notes, verbose-error-to)) != NULL
+ if ((apr_pool_userdata_get((void **)error_notes, error_notes,
+ r-pool) == APR_SUCCESS)
+ error_notes
+ (apr_pool_userdata_get((void **)h1, verbose-error-to,
+ r-pool) == APR_SUCCESS)
+ h1
(strcmp(h1, *) == 0)) {
return(apr_pstrcat(p, error_notes, p /\n, NULL));
}
Index: modules/http/http_request.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/http/http_request.c,v
retrieving revision 1.113
diff -u -r1.113 http_request.c
--- modules/http/http_request.c 2001/08/31 03:49:42 1.113
+++ modules/http/http_request.c 2001/09/16 23:42:19
@@ -204,8 +204,12 @@
* more informative (than the plain canned) messages to us.
* Propagate them to ErrorDocuments via the ERROR_NOTES variable:
*/
-if ((error_notes = apr_table_get(r-notes, error-notes)) != NULL) {
- apr_table_setn(r-subprocess_env, ERROR_NOTES, error_notes);
+if (APR_STATUS_IS_SUCCESS(apr_pool_userdata_get((void **)error_notes,
+error-notes,
+r-pool))
+ error_notes) {
+apr_pool_userdata_set(error_notes,
Re: [SUBMIT] mod_gzip 2.0.26a ( Non-debug version )
In a message dated 01-09-16 15:38:37 EDT, Cliff wrote... I should have been more explicit. It's not bogus to do a conditional like the one you just displayed. I thought it was excessive to make it a whole separate function that's only used in one place. I thought it was bogus to set it to the string NULL instead of the empty string, though coincidentally a string that says NULL works out fine in the one place where this function is used. Then there the fact that I can't think of a way that r-uri would ever be NULL. Can it really? Even when there is no r-uri, we set it to the empty string. That was that whole INTERNALLY GENERATED bogosity that we scratched our heads over for a while and then Ryan fixed it by setting it to . Under what circumstances will r-uri==NULL? That call to mod_gzip_npp() ( Null Pointer Protection ) that remains in the debug code was actually an oversight. I have never actually seen the 'r-uri' pointer cause a segfault inside any standard Apache module user-exit, hook, or filter callback. If you look at the 'debug' version of mod_gzip.c that was submitted, however, you will see that it was quite necessary to have NPP for debug mode since there are tons of places where debug is trying to print things that might very well be NULL. Solaris version started exploding all over the place in DEBUG mode just because pointers were NULL so that's when the Null Pointer Protection stuff went in. The reason it's a function is that it used to do a whole lot of other things if/when something showed up as NULL ) that weren't apppriate for a macro ( Used to write a complete separate log file for things that turned up NULL during request hooks and such ). In non-debug mode... it's really all pretty irrelevant. Yours... Kevin
