Hi -- First of all, thanks for the very useful module! It's working very nicely for me (with the patches described in my previous email).
I do have a few things I'd love to see changed or fixed in a future release of mod_fcgid: 1) It's not ideal that the mod_fcgid configuration directives don't have a standard prefix like "FastCGI" or "Fcgi" or something. Others have commented on this too: http://blog.duncandavidson.com/2006/02/rails_on_apache.html In particular, directives like MaxRequestsPerProcess, OutputBufferSize, MaxProcessCount, SocketPath, and so forth could easily happen to be in use by someone else's third-party module. Using a standard prefix for all directives means there's less change of "namespace" collisions, and is also really helpful for system administrators. I can provide a patch to do this if others agree; I'll probably write such a patch anyway for my own convenience. On the same note, some of the configuration directive names are a little puzzling, for example, DefaultMaxClassProcessCount -- why not just MaxClassProcessCount? (Or, better still, FastCGIMaxClassProcessCount. :-) 2) I notice that overrides of values such as BusyTimeout in <VirtualHost> sections is no longer supported by the code in CVS HEAD. That's fine, obviously. However, you might want to add a check in the command handler so that using such configuration directives ihttpn <VirtualHost> or <Limit> sections causes an error. Combined with the RSRC_CONF value, this corresponds to the correct usage locations, I think. Here's an example: const char *set_max_class_process(cmd_parms * cmd, void *dummy, const char *arg) { server_rec *s = cmd->server; fcgid_server_conf *config; const char *err; if((err = ap_check_cmd_context(cmd, NOT_IN_VIRTUALHOST | NOT_IN_LIMIT)) != NULL) { return err; } config = ap_get_module_config(s->module_config, &fcgid_module); config->max_class_process_count = atol(arg); return NULL; } Again, if I get a chance I might try to add these checks; but I won't make any promises. 3) The process manager is only started once, when the server is initially started. That means it won't see any changes made to configuration directives like MaxProcessCount until the next time the server is completely stopped and then started again. Just performing a restart (graceful or not) isn't sufficient. If at all possible, it would be great to fix this. If this can't be easily fixed, I suggest at least trying to alert system administrators by logging a warning that the new values are being ignored. Other configuration directives that can't be changed across restarts work like this too; see, for example, ServerLimit and MaxClients. It would also be nice to do some sanity checking during the server startup configuration phases. For example, MaxProcessCount should presumably always be greater than or equal to DefaultMaxClassProcessCount. As it happens, there isn't a great place for doing sanity checks in httpd 2.2 and below. In the trunk version of httpd, I have added a check_config phase which allows for this kind of sanity checking, as well as being a good place to alert system administrators to values being ignored during a restart. See, for example, the check_config handlers of the prefork and worker MPMs in httpd trunk: http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/prefork/prefork.c?view=markup http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/worker/worker.c?view=markup So, to some extent, it might be better to wait for httpd 2.4 and then implement any sanity checks. The reporting of changes to configuration values that are being ignored, though, is certainly possible in httpd 2.2 and below. Once again, thanks for the fine module. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Mod-fcgid-users mailing list Mod-fcgid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users
