Suggestion for Apache HTTP Server: Use lighttpd worker
I have a suggestion. So the apache worker MPM is not being maintained anymore, so Apache should just use the worker feature that lighttpd has and tweak it so it works with apache HTTP Server. Save alot of time and effort.
Re: Suggestion for Apache HTTP Server: Use lighttpd worker
tim...@email.com wrote: I have a suggestion. So the apache worker MPM is not being maintained anymore, so Apache should just use the worker feature that lighttpd has and tweak it so it works with apache HTTP Server. Save alot of time and effort. I'm not aware that support for worker has been dropped or is no longer maintained? Regards, Graham --
Re: Suggestion for Apache HTTP Server: Use lighttpd worker
On Tue, Nov 24, 2009 at 5:53 AM, Graham Leggett minf...@sharp.fm wrote: tim...@email.com wrote: I have a suggestion. So the apache worker MPM is not being maintained anymore, so Apache should just use the worker feature that lighttpd has and tweak it so it works with apache HTTP Server. Save alot of time and effort. I'm not aware that support for worker has been dropped or is no longer maintained? It ain't so. worker is the default MPM on some platforms in future Apache 2.4.
Re: svn commit: r883540 - in /httpd/httpd/trunk: ./ build/ docs/conf/ docs/conf/extra/ include/ modules/aaa/ modules/core/ modules/examples/ modules/generators/ modules/ldap/ modules/mappers/ module
On Mon, Nov 23, 2009 at 6:59 PM, Jeff Trawick traw...@gmail.com wrote: On Mon, Nov 23, 2009 at 6:33 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: traw...@apache.org wrote: Author: trawick Date: Mon Nov 23 23:17:51 2009 New Revision: 883540 URL: http://svn.apache.org/viewvc?rev=883540view=rev Log: Replace AcceptMutex, LockFile, RewriteLock, SSLMutex, SSLStaplingMutex, and WatchdogMutexPath with a single Mutex directive. Add APIs to simplify setup and user customization of APR proc and global mutexes. (See util_mutex.h.) Build-time setting DEFAULT_LOCKFILE is no longer respected; set DEFAULT_REL_RUNTIMEDIR instead. I haven't spent enough time follow the discussion thread, but there is a pretty big concern here. Let's say we pick NFS for our SSL session store, which means we need an fcntl or file lock to mutex the session cache. But if these others were all machine local (and hopefully, easily threadproc mutexible, such as a pthread mutex or at worst case, a sysv sem) then the optimal no longer mirrors the appropriate match based on the resource. Can we perhaps partially revert to allow these to be -overrides- of the system wide mutex mechanism, e.g. sysv sem might be right for all but two resources. Let those two be overridden (and point out, in the docs, when this would become necessary). What is missing for your scenario AFAICT is having a predictable lock file name so that different nodes can share the same mutex file. Currently on Unix the pid will always be appended to the lock file name. Interestingly, the mod_ssl doc currently states that the pid will be appended automatically to the file specified in SSLMutex. You removed the corresponding code in 2003 with the comment It also removes the mod_ssl historical '.pid' suffixes - that isn't how Apache2 specifies files.
Re: svn commit: r883712 - /httpd/httpd/trunk/docs/manual/mod/core.xml
On Tue, Nov 24, 2009 at 9:54 AM, traw...@apache.org wrote: Author: trawick Date: Tue Nov 24 14:54:03 2009 New Revision: 883712 URL: http://svn.apache.org/viewvc?rev=883712view=rev Log: document the new Mutex directive, pulling in any existing special considerations described in the documentation of the old LockFile, AcceptMutex, RewriteLock, and SSLMutex directives I'll axe the old directive documentation and update any other affected documentation once wrowe's concern about cross-node lock files is resolved (barring any other concerns I'm yet to be informed of ;) ).
[mod_fcgid] Feedback / Suggestions
Hi dev, I'd like to suggest to following changes / offer feedback for mod_fcgid: (1) mod_fcgid should be capable of specifying an external FCGI server. Assume a scenario where the backend FCGI server (e.g. PHP with php-fpm) runs for security considerations prespawned on a separate machine with a firewall only letting FCGI traffic through. This is possible with mod_proxy_fcgi or mod_fastcgi (with mod_proxy_fcgi only being in trunk and mod_fastcgi kinda outdated). (2) In conjunction with (1), mod_fcgid should be able to select the backend server based on request data. Current, this kind of behaviour is possible with mod_proxy and mod_proxy_fcgi using either interpolated environment variables and/or mod_rewrite with the [P] suffix in a RewriteRule. Unfortunately mod_proxy_fcgi currently exists only in trunk, seems to be kind of abandoned and has some bugs (I filed two bug reports in BZ under 48272 and 48273). As mod_fcgid seems to be the current weapon of choice, it would be great to have this feature(s) in mod_fcgid (or mod_proxy_fcgi fixed otherwise). Admittedly I have a urgent need for this feature in a production environment. If this feature can't be implemented (respectivly fixed) in the near future (which can I fully understand as a software developer), what would be your suggestion to get an Apache running this way? I'd really hate it to abandon Apache because of this (and am willing to do something against it as far as I still have time in my current project) (3) mod_fcgid currently buffers the complete input from the client (occasionaly in a temp-file if the request is large) before it passes it through to a FCGI backend. Could this be made configurable in a way like File|Memory|Pipeline? (file - as is | memory - buffer in memory always | pipeline - directly pass the read data to the backend) Or otherwise, can someone explain the details to me why it is as it is? Especially in terms of not pipeling data directly (maybe after a little buffering to build proper FCGI packets)? The comment in fcgid_bridge.c:452 (add_request_body) left me clueless. Why would this keep the server in processing too long? Processing takes its time either way, I'd assume. Looking forward to enlightment. :) (4) Would it make sense to use the FCGI feature to multiplex several requests over a single connection? Does any backend support this feature anyway? When thinking of an external FCGI backend with a socket connection and very high Requests/s, this could keep open connections and used/available ports much lower. Really looking forward to your comments. Regards, Edgar Frank
Re: [mod_fcgid] Feedback / Suggestions
On Tue, Nov 24, 2009 at 10:05 AM, Edgar Frank ef-li...@email.de wrote: Hi dev, I'd like to suggest to following changes / offer feedback for mod_fcgid: my 2cents below (1) mod_fcgid should be capable of specifying an external FCGI server. (2) In conjunction with (1), mod_fcgid should be able to select the backend server based on request data. I'd much rather see effort put into mod_proxy_fcgi to support this use case. I wish somebody, perhaps myself, had time to work on it. It doesn't seem that hard a task. In the interim, is mod_fastcgi really that bad? (3) mod_fcgid currently buffers the complete input from the client (occasionaly in a temp-file if the request is large) before it passes it through to a FCGI backend. Could this be made configurable in a way like File|Memory|Pipeline? (file - as is | memory - buffer in memory always | pipeline - directly pass the read data to the backend) This will definitely be resolved ;) Or otherwise, can someone explain the details to me why it is as it is? Especially in terms of not pipeling data directly (maybe after a little buffering to build proper FCGI packets)? The comment in fcgid_bridge.c:452 (add_request_body) left me clueless. Why would this keep the server in processing too long? Processing takes its time either way, I'd assume. Looking forward to enlightment. :) I can only guess that the problem at hand when this was implemented was that some backend application processes were so expensive that that they couldn't be tied up until all data had been read from slow clients. (4) Would it make sense to use the FCGI feature to multiplex several requests over a single connection? Does any backend support this feature anyway? no idea here When thinking of an external FCGI backend with a socket connection and very high Requests/s, this could keep open connections and used/available ports much lower.
Re: [mod_fcgid] Feedback / Suggestions
On Tue, Nov 24, 2009 at 4:24 PM, Jeff Trawick traw...@gmail.com wrote: (1) mod_fcgid should be capable of specifying an external FCGI server. (2) In conjunction with (1), mod_fcgid should be able to select the backend server based on request data. I'd much rather see effort put into mod_proxy_fcgi to support this use case. I wish somebody, perhaps myself, had time to work on it. It doesn't seem that hard a task. What was the reason to import mod_fcgi again? Wasn't the ETA of mod_proxy_fcgi too high? In the interim, is mod_fastcgi really that bad? I assume mod_fcgi wasn't developed without proper reason. Olaf
a directive to select the pollset implementation?
As with mutex implementations, APR pollset implementations, or the
underlying OS support, are occasionally broken for some
configurations; the access to multiple implementations in APR 1.4.x
lends itself to allowing the user to specify a non-default pollset
implementation.
For example, the following could be used to work around the temporary
epoll sysdef confusion on Linux, or (cough) the port_getn() interface
challenges on Solaris:
# use poll() instead of epoll/port_create/kqueue/whatever
Poll default poll
As with the Mutex directive directive, a module would register a poll
type name in the pre-config hook then call
ap_{pollcb,pollset}_create() in lieu of apr_{pollcb,pollset}_create(),
and magic would happen.
APR pollsets have a special consideration that mutexes do not: Some
features such as APR_POLLSET_THREADSAFE are optional, and not
implemented uniformly among underlying implementations. The simple
and event MPMs require this particular optional feature. The Poll
directive would not provide any special magic here. If you declare
Poll default poll and try to use the Simple MPM, the Simple MPM
would fail startup. You could of course configure
Poll default poll
Poll simple-io eventport # or epoll
to work around the startup failure, but that most likely defeats the
original purpose -- avoiding a problem in the advanced implementation.
--/--
Beyond working around implementation problems, perhaps the ease of
selection in an important application would motivate developers to
support more mechanisms in APR?
Re: [mod_fcgid] Feedback / Suggestions
On Tue, Nov 24, 2009 at 10:34 AM, Olaf van der Spek olafvds...@gmail.com wrote: On Tue, Nov 24, 2009 at 4:24 PM, Jeff Trawick traw...@gmail.com wrote: (1) mod_fcgid should be capable of specifying an external FCGI server. (2) In conjunction with (1), mod_fcgid should be able to select the backend server based on request data. I'd much rather see effort put into mod_proxy_fcgi to support this use case. I wish somebody, perhaps myself, had time to work on it. It doesn't seem that hard a task. What was the reason to import mod_fcgi again? Wasn't the ETA of mod_proxy_fcgi too high? mod_fcgid was imported because it was * widely used * not actively maintained * httpd developers were willing to adopt it I felt that it was a nice addition particularly because it had a different approach to this important problem space compared with mod_proxy_fcgi. In the interim, is mod_fastcgi really that bad? I assume mod_fcgi wasn't developed without proper reason. So do I. (FWIW, I've put a lot of time into mod_fcgid and expect to continue doing so in the future.) The situation at hand seems to be * mod_proxy_fcgi promises to meet those requirements but falls short at present * mod_fcgid doesn't even try * mod_fastcgi implements at least some of those requirements and is mature
Re: [mod_fcgid] Feedback / Suggestions
-- From: Jeff Trawick traw...@gmail.com Sent: Tuesday, November 24, 2009 11:24 PM To: dev@httpd.apache.org Subject: Re: [mod_fcgid] Feedback / Suggestions On Tue, Nov 24, 2009 at 10:05 AM, Edgar Frank ef-li...@email.de wrote: Hi dev, I'd like to suggest to following changes / offer feedback for mod_fcgid: my 2cents below (1) mod_fcgid should be capable of specifying an external FCGI server. (2) In conjunction with (1), mod_fcgid should be able to select the backend server based on request data. I'd much rather see effort put into mod_proxy_fcgi to support this use case. I wish somebody, perhaps myself, had time to work on it. It doesn't seem that hard a task. In the interim, is mod_fastcgi really that bad? (3) mod_fcgid currently buffers the complete input from the client (occasionaly in a temp-file if the request is large) before it passes it through to a FCGI backend. Could this be made configurable in a way like File|Memory|Pipeline? (file - as is | memory - buffer in memory always | pipeline - directly pass the read data to the backend) This will definitely be resolved ;) Pipeline is a little complex. FastCGI process would write during reading. so mod_fcgid should check both read and write on the socket, and read/write while the socket is readable/writeable. But is do-able :) Any one interesting? Or otherwise, can someone explain the details to me why it is as it is? Especially in terms of not pipeling data directly (maybe after a little buffering to build proper FCGI packets)? The comment in fcgid_bridge.c:452 (add_request_body) left me clueless. Why would this keep the server in processing too long? Processing takes its time either way, I'd assume. Looking forward to enlightment. :) I can only guess that the problem at hand when this was implemented was that some backend application processes were so expensive that that they couldn't be tied up until all data had been read from slow clients. Yes, Jeff is right :) (4) Would it make sense to use the FCGI feature to multiplex several requests over a single connection? Does any backend support this feature anyway? no idea here In this case, one httpd thread(process) will have to bind to one FastCGI process. I don't think connect() to a local pipe/unix domain socket is the bottle-neck, so let it be? When thinking of an external FCGI backend with a socket connection and very high Requests/s, this could keep open connections and used/available ports much lower. connect() may be bottle-neck if using external FCGI backend. But now mod_fcgid don't support external FCGI backend yet.
Re: [mod_fcgid] Feedback / Suggestions
On Tue, Nov 24, 2009 at 4:47 PM, Jeff Trawick traw...@gmail.com wrote: What was the reason to import mod_fcgi again? Wasn't the ETA of mod_proxy_fcgi too high? mod_fcgid was imported because it was * widely used * not actively maintained * httpd developers were willing to adopt it I felt that it was a nice addition particularly because it had a different approach to this important problem space compared with mod_proxy_fcgi. What advantages does fcgid have over proxy_fcgi (except being ready)? In the interim, is mod_fastcgi really that bad? I assume mod_fcgi wasn't developed without proper reason. So do I. (FWIW, I've put a lot of time into mod_fcgid and expect to continue doing so in the future.) The situation at hand seems to be * mod_proxy_fcgi promises to meet those requirements but falls short at present * mod_fcgid doesn't even try * mod_fastcgi implements at least some of those requirements and is mature mod_fcgid isn't in 2.2, right? So what's the plan for 2.4? Have both of them? Or is mod_proxy_fcgi expected to be not ready for 2.4? Olaf
Re: [mod_fcgid] Feedback / Suggestions
On Tue, Nov 24, 2009 at 4:50 PM, pqf p...@mailtech.cn wrote: In this case, one httpd thread(process) will have to bind to one FastCGI process. I don't think connect() to a local pipe/unix domain socket is the bottle-neck, so let it be? Doesn't it require an extra round trip? It's probably not too bad, but would be nice to avoid. Olaf
Re: [mod_fcgid] Feedback / Suggestions
On Tue, Nov 24, 2009 at 10:58 AM, Olaf van der Spek olafvds...@gmail.com wrote: On Tue, Nov 24, 2009 at 4:47 PM, Jeff Trawick traw...@gmail.com wrote: What was the reason to import mod_fcgi again? Wasn't the ETA of mod_proxy_fcgi too high? mod_fcgid was imported because it was * widely used * not actively maintained * httpd developers were willing to adopt it I felt that it was a nice addition particularly because it had a different approach to this important problem space compared with mod_proxy_fcgi. What advantages does fcgid have over proxy_fcgi (except being ready)? integrated, on-demand process management In the interim, is mod_fastcgi really that bad? I assume mod_fcgi wasn't developed without proper reason. So do I. (FWIW, I've put a lot of time into mod_fcgid and expect to continue doing so in the future.) The situation at hand seems to be * mod_proxy_fcgi promises to meet those requirements but falls short at present * mod_fcgid doesn't even try * mod_fastcgi implements at least some of those requirements and is mature mod_fcgid isn't in 2.2, right? mod_fcgid is actually not bundled with the HTTP server. It is released on its own cycle, and supports httpd 2.0.x, 2.2.x, and trunk (future httpd 2.4.x) with one delivery. So what's the plan for 2.4? Have both of them? Or is mod_proxy_fcgi expected to be not ready for 2.4? mod_fcgid will support 2.4. proxy-fcgi folk(s), care to speak up on your baby?
Re: [mod_fcgid] Feedback / Suggestions
On Tue, Nov 24, 2009 at 10:50 AM, pqf p...@mailtech.cn wrote: (3) mod_fcgid currently buffers the complete input from the client (occasionaly in a temp-file if the request is large) before it passes it through to a FCGI backend. Could this be made configurable in a way like File|Memory|Pipeline? (file - as is | memory - buffer in memory always | pipeline - directly pass the read data to the backend) This will definitely be resolved ;) Pipeline is a little complex. FastCGI process would write during reading. so mod_fcgid should check both read and write on the socket, and read/write while the socket is readable/writeable. But is do-able :) Any one interesting? I'm interested, but need to find adequate time. (I can certainly find time to review and help test somebody else's implementation.) Or otherwise, can someone explain the details to me why it is as it is? Especially in terms of not pipeling data directly (maybe after a little buffering to build proper FCGI packets)? The comment in fcgid_bridge.c:452 (add_request_body) left me clueless. Why would this keep the server in processing too long? Processing takes its time either way, I'd assume. Looking forward to enlightment. :) I can only guess that the problem at hand when this was implemented was that some backend application processes were so expensive that that they couldn't be tied up until all data had been read from slow clients. Yes, Jeff is right :) This is a reasonable feature; once streaming to the app is implemented this alternate mechanism can be enabled with a per-request envvar (e.g., SetEnv in the directory or location).
Re: [mod_fcgid] Feedback / Suggestions
On Tue, Nov 24, 2009 at 5:03 PM, Jeff Trawick traw...@gmail.com wrote: What advantages does fcgid have over proxy_fcgi (except being ready)? integrated, on-demand process management How valuable is that? In most cases a static number of backends seems fine. mod_fcgid isn't in 2.2, right? mod_fcgid is actually not bundled with the HTTP server. It is released on its own cycle, and supports httpd 2.0.x, 2.2.x, and trunk (future httpd 2.4.x) with one delivery. Ah, nice. What's the reason it's not bundled though? In this case, I'd love to see support for TCP/IP backends too. Shouldn't be too hard to implement. So what's the plan for 2.4? Have both of them? Or is mod_proxy_fcgi expected to be not ready for 2.4? mod_fcgid will support 2.4. proxy-fcgi folk(s), care to speak up on your baby? Olaf
Re: [mod_fcgid] Feedback / Suggestions
(1) mod_fcgid should be capable of specifying an external FCGI server. (2) In conjunction with (1), mod_fcgid should be able to select the backend server based on request data. I'd much rather see effort put into mod_proxy_fcgi to support this use case. I wish somebody, perhaps myself, had time to work on it. It doesn't seem that hard a task. mod_proxy_fcgi already supports this use case completely, if it weren't for the two bugs I filed. While I see BZ#48273 as not-so-big issue, BZ#48272 presents a potential crash for the Apache process, which excludes it for production use. As far as I have understood the problem in BZ#48272, this is a real design issue in mod_proxy_fcgi, as it tries to stream the response by design while ap_scan_header_err_core wants the complete script output by design. In the interim, is mod_fastcgi really that bad? Lets say, it works (fine) in terms that you can specify an external server. I took modifying mod_fastcgi into account to add the functionality for dynamic backend-switching, but refrained from doing so as the source code is made to work with Apache 1.x/2.0/2.2 with lots of #ifdefs, only partial APR support (handful of things are done on OS level) and additional Win32-kludges. Additionally, mod_fastcgi reads its backend servers at configuration time and access them at runtime readonly. Modifying this would mean to add thread safty to the source, if you want to use it in the worker mpm. Considering the sourcecode, this would be a bad job.
Re: svn commit: r883712 - /httpd/httpd/trunk/docs/manual/mod/core.xml
Jeff Trawick wrote: On Tue, Nov 24, 2009 at 9:54 AM, traw...@apache.org wrote: Author: trawick Date: Tue Nov 24 14:54:03 2009 New Revision: 883712 URL: http://svn.apache.org/viewvc?rev=883712view=rev Log: document the new Mutex directive, pulling in any existing special considerations described in the documentation of the old LockFile, AcceptMutex, RewriteLock, and SSLMutex directives I'll axe the old directive documentation and update any other affected documentation once wrowe's concern about cross-node lock files is resolved (barring any other concerns I'm yet to be informed of ;) ). It sounds like this is resolved, and was nothing more than the confusion I introduced when I didn't update the docs to match the code revision. Sorry about that - I presume your patch will simply normalize all this documentation, and we can call it a day. Looking forward to the directive docs, happy to review!
Re: svn commit: r883712 - /httpd/httpd/trunk/docs/manual/mod/core.xml
On Tue, Nov 24, 2009 at 11:53 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Jeff Trawick wrote: On Tue, Nov 24, 2009 at 9:54 AM, traw...@apache.org wrote: Author: trawick Date: Tue Nov 24 14:54:03 2009 New Revision: 883712 URL: http://svn.apache.org/viewvc?rev=883712view=rev Log: document the new Mutex directive, pulling in any existing special considerations described in the documentation of the old LockFile, AcceptMutex, RewriteLock, and SSLMutex directives I'll axe the old directive documentation and update any other affected documentation once wrowe's concern about cross-node lock files is resolved (barring any other concerns I'm yet to be informed of ;) ). It sounds like this is resolved, I'm not so sure ;) and was nothing more than the confusion I introduced when I didn't update the docs to match the code revision. It is true that your requirement (as I understand it) for the SSL session cache mutex -- that the complete name be fully predictable/configurable and not contain the pid -- was not reflected in the docs. But the Mutex directive and ap_mutex_*() APIs don't currently support that requirement, always appending a pid to the name of the lock file. What about an optional third argument to Mutex to indicate that the pid should be omitted? Mutex default sysvsem Mutex ssl-cache file:/mnt/sesscachedir OmitPid etc. In the ssl-cache example, the name of the mutex will be simply /mnt/sesscachedir/ssl-cache Does that meet the special SSLMutex requirement?
Re: svn commit: r883540 - in /httpd/httpd/trunk: ./ build/ docs/conf/ docs/conf/extra/ include/ modules/aaa/ modules/core/ modules/examples/ modules/generators/ modules/ldap/ modules/mappers/ module
Jeff Trawick wrote: On Mon, Nov 23, 2009 at 6:17 PM, traw...@apache.org wrote: Author: trawick Date: Mon Nov 23 23:17:51 2009 New Revision: 883540 URL: http://svn.apache.org/viewvc?rev=883540view=rev There will likely be other issues to discuss about this, but to start with: * you need an extremely recent checkout of apr-1.4.x in order to get apr_global_mutex_lockfile() VC6 SP6 SDK 2003R2 VC9 SP1 SDK Included Express Checkout APR 1.4 post r883540 --- httpd/httpd/trunk/server/util_mutex.c 2009/03/26 12:44:48 758613 +++ httpd/httpd/trunk/server/util_mutex.c 2009/11/23 23:17:51 883540 @@ -31,7 +32,12 @@ #include httpd.h #include http_main.h #include http_config.h +#include http_log.h #include util_mutex.h +#include unixd.h +#ifdef HAVE_UNISTD_H +#include unistd.h /* getpid() */ +#endif #include unixd.h in the open and anything associated with it is going to bring Visual Studio to it's knees. I see this in other places (socache modules at least) #if AP_NEED_SET_MUTEX_PERMS #include unixd.h #endif and maybe /* Check for definition of DEFAULT_REL_RUNTIMEDIR */ #ifndef DEFAULT_REL_RUNTIMEDIR #define DEFAULT_DBM_PREFIX whatever_it_should_be #else #define DEFAULT_DBM_PREFIX DEFAULT_REL_RUNTIMEDIR whatever #endif since it is not picking it up from mpm_default.h VC6/9 doesn't seem too thrilled with this in core.c AP_INIT_TAKE2(Mutex, ap_set_mutex, NULL, RSRC_CONF, mutex (or \default\) and mechanism), VC6 E:\build\httpd-2.3.x-dev\server\core.c(3323) : error C2152: 'initializing' : pointers to functions with different attributes VC9 .\server\core.c(3323) : error C2440: 'initializing' : cannot convert from 'const char *(__stdcall *)(cmd_parms *,void *,const char *,const char *)' to 'cmd_func' not quite sure what it is telling me here other than possibly ap_set_mutex is not returning a string, not sure. Regards, Gregg
Re: svn commit: r883540 - in /httpd/httpd/trunk: ./ build/ docs/conf/ docs/conf/extra/ include/ modules/aaa/ modules/core/ modules/examples/ modules/generators/ modules/ldap/ modules/mappers/ module
On Tue, Nov 24, 2009 at 12:46 PM, Gregg L. Smith li...@glewis.com wrote:
Jeff Trawick wrote:
On Mon, Nov 23, 2009 at 6:17 PM, traw...@apache.org wrote:
Author: trawick
Date: Mon Nov 23 23:17:51 2009
New Revision: 883540
URL: http://svn.apache.org/viewvc?rev=883540view=rev
There will likely be other issues to discuss about this, but to start
with:
* you need an extremely recent checkout of apr-1.4.x in order to get
apr_global_mutex_lockfile()
VC6 SP6 SDK 2003R2
VC9 SP1 SDK Included Express
Checkout APR 1.4 post r883540
--- httpd/httpd/trunk/server/util_mutex.c 2009/03/26 12:44:48 758613
+++ httpd/httpd/trunk/server/util_mutex.c 2009/11/23 23:17:51 883540
@@ -31,7 +32,12 @@
#include httpd.h
#include http_main.h
#include http_config.h
+#include http_log.h
#include util_mutex.h
+#include unixd.h
+#ifdef HAVE_UNISTD_H
+#include unistd.h /* getpid() */
+#endif
#include unixd.h in the open and anything associated with it is going
to bring Visual Studio to it's knees.
fixed in r883802
I see this in other places (socache modules at least)
#if AP_NEED_SET_MUTEX_PERMS
#include unixd.h
#endif
yep
and maybe
/* Check for definition of DEFAULT_REL_RUNTIMEDIR */
#ifndef DEFAULT_REL_RUNTIMEDIR
#define DEFAULT_DBM_PREFIX whatever_it_should_be
#else
#define DEFAULT_DBM_PREFIX DEFAULT_REL_RUNTIMEDIR whatever
#endif
since it is not picking it up from mpm_default.h
I don't follow you on this one
VC6/9 doesn't seem too thrilled with this in core.c
AP_INIT_TAKE2(Mutex, ap_set_mutex, NULL, RSRC_CONF,
mutex (or \default\) and mechanism),
VC6 E:\build\httpd-2.3.x-dev\server\core.c(3323) : error C2152:
'initializing' : pointers to functions with different attributes
VC9 .\server\core.c(3323) : error C2440: 'initializing' : cannot convert
from 'const char *(__stdcall *)(cmd_parms *,void *,const char *,const
char *)' to 'cmd_func'
not quite sure what it is telling me here other than possibly ap_set_mutex
is not returning a string, not sure.
calling convention incompatibility; I guess the command function
macros have hard-coded a particular calling convention that is
different from our API calling convent (AP_DECLARE())
can you try the attached patch pretty please?
Thanks!
Index: include/util_mutex.h
===
--- include/util_mutex.h(revision 883688)
+++ include/util_mutex.h(working copy)
@@ -99,9 +99,9 @@
const char **mutexfile);
/* private function to process the Mutex directive */
-AP_DECLARE(const char *) ap_set_mutex(cmd_parms *cmd, void *dummy,
- const char *typelist,
- const char *mechfile);
+const char * ap_set_mutex(cmd_parms *cmd, void *dummy,
+ const char *typelist,
+ const char *mechfile);
/**
* option flags for ap_mutex_register(), ap_global_mutex_create(), and
Index: server/util_mutex.c
===
--- server/util_mutex.c (revision 883802)
+++ server/util_mutex.c (working copy)
@@ -160,8 +160,8 @@
apr_hash_set(mxcfg_by_type, default, APR_HASH_KEY_STRING, def);
}
-AP_DECLARE(const char *) ap_set_mutex(cmd_parms *cmd, void *dummy,
- const char *type, const char *mechdir)
+const char * ap_set_mutex(cmd_parms *cmd, void *dummy,
+ const char *type, const char *mechdir)
{
apr_pool_t *p = cmd-pool;
apr_lockmech_e mech;
Re: svn commit: r883712 - /httpd/httpd/trunk/docs/manual/mod/core.xml
Jeff Trawick wrote: What about an optional third argument to Mutex to indicate that the pid should be omitted? Mutex default sysvsem Mutex ssl-cache file:/mnt/sesscachedir OmitPid etc. That seems sensible, but I'm left wondering how many different naming conventions we can fit on one directive line. Perhaps bOmitPID instead ;-) This really becomes harder to follow than the existing multiple-syntaxes. Is there any reason not to name these mutexes in MixedCase? Is there any reason we can't invert the arg order, so that we have Mutex mutextype:name Resource [Resource ...] [OmitPid] Of course, default could be assumed here. So the above becomes Mutex SysVSem Mutex file:/mnt/sesscachedir SSLSessionCache OmitPid (note the Resource tag can be the actual directive being mutexed, instead of an alt-name). Thoughts? In the ssl-cache example, the name of the mutex will be simply /mnt/sesscachedir/ssl-cache Does that meet the special SSLMutex requirement? Well, it's not strictly SSLMutex, but any other shared-resource that requires cross process/cross machine mutexing.
Re: svn commit: r883540 - in /httpd/httpd/trunk: ./ build/ docs/conf/ docs/conf/extra/ include/ modules/aaa/ modules/core/ modules/examples/ modules/generators/ modules/ldap/ modules/mappers/ module
Maybe I should add, build will fail on line util_mutex.c line 160 unless DEFAULT_REL_RUNTIMEDIR is defined, whether by also including mpm_default.h or adding a define in util_mutex.c or util_mutex.h. E:\build\httpd-2.3.x-dev\server\util_mutex.c(159) : error C2065: 'DEFAULT_REL_RUNTIMEDIR' : undeclared identifier Sorry for the lack of clarity again. Gregg Gregg L. Smith wrote: Jeff Trawick wrote: On Tue, Nov 24, 2009 at 12:46 PM, Gregg L. Smith li...@glewis.com wrote: Jeff Trawick wrote: Ok, let me express it this way. in util_mutex.c line 160 you've got this; def-dir = DEFAULT_REL_RUNTIMEDIR; The only place I find DEFAULT_REL_RUNTIMEDIR defined is in mpm_default.h You do not include mpm_default.h most likely since it would introduce a lot of excess baggage, understandable. So if you do not want to include the excess baggage, it must defind in the util_mutex.c no? Similar again to the socache modules which I stole that code snip from. I'm just not sure what the whatever_it_should_be and whatever should actually be. In server/mpm/winnt/mpm_default.h it's just the one logs (lines 64-67) /* Check for definition of DEFAULT_REL_RUNTIMEDIR */ #ifndef DEFAULT_REL_RUNTIMEDIR #define DEFAULT_REL_RUNTIMEDIR logs #endif However in mod_socache_dbm.c (lines 56-61) for example it's /* Check for definition of DEFAULT_REL_RUNTIMEDIR */ #ifndef DEFAULT_REL_RUNTIMEDIR #define DEFAULT_DBM_PREFIX logs/socache-dbm- #else #define DEFAULT_DBM_PREFIX DEFAULT_REL_RUNTIMEDIR /socache-dbm- #endif Do you follow me now? There's a similar 'use before checking if it's defined' in mod_ldap as well but that's another issue that does not concern this. calling convention incompatibility; I guess the command function macros have hard-coded a particular calling convention that is different from our API calling convent (AP_DECLARE()) can you try the attached patch pretty please? most certainly can and did and the build passes that point and she will at least serve up a It works!. Stoopid Windoze ;-) Gregg
Re: svn commit: r883540 - in /httpd/httpd/trunk: ./ build/ docs/conf/ docs/conf/extra/ include/ modules/aaa/ modules/core/ modules/examples/ modules/generators/ modules/ldap/ modules/mappers/ module
On Tue, Nov 24, 2009 at 2:24 PM, Gregg L. Smith li...@glewis.com wrote: Maybe I should add, build will fail on line util_mutex.c line 160 unless DEFAULT_REL_RUNTIMEDIR is defined, whether by also including mpm_default.h or adding a define in util_mutex.c or util_mutex.h. E:\build\httpd-2.3.x-dev\server\util_mutex.c(159) : error C2065: 'DEFAULT_REL_RUNTIMEDIR' : undeclared identifier Sorry for the lack of clarity again. no, even I could understand I fixed it by hardcoding logs when DEFAULT_REL_RUNTIMEDIR isn't defined. (mpm_default.h won't be found on Unix without build changes, and we want to minimize affinity with any particular MPM anyway.) I left a note to clean up access to DEFAULT_REL_RUNTIMEDIR for some other rainy day.
Re: svn commit: r883816 - in /httpd/httpd/trunk: include/util_mutex.h server/util_mutex.c
traw...@apache.org wrote: --- httpd/httpd/trunk/include/util_mutex.h (original) +++ httpd/httpd/trunk/include/util_mutex.h Tue Nov 24 19:06:16 2009 @@ -99,9 +99,9 @@ const char **mutexfile); /* private function to process the Mutex directive */ -AP_DECLARE(const char *) ap_set_mutex(cmd_parms *cmd, void *dummy, - const char *typelist, - const char *mechfile); If this is a public function (and it is named as one) please revert ;-)
Re: svn commit: r883712 - /httpd/httpd/trunk/docs/manual/mod/core.xml
On Tue, Nov 24, 2009 at 1:58 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Jeff Trawick wrote: What about an optional third argument to Mutex to indicate that the pid should be omitted? Mutex default sysvsem Mutex ssl-cache file:/mnt/sesscachedir OmitPid etc. That seems sensible, but I'm left wondering how many different naming conventions we can fit on one directive line. Perhaps bOmitPID instead ;-) This really becomes harder to follow than the existing multiple-syntaxes. Is there any reason not to name these mutexes in MixedCase? I like having the mutex type name as of the filename, and mixed case filenames are unexpected. Beyond that, MixedCase and the . before the pid suffix don't totally resolve readability. Modules like mod_watchdog with multi-instance mutexes provide an instance string which gets inserted as - string prior to the . pid suffix. If the watchdog names are heartbeat and dialup (wild guess; I didn't look closely or try to configure the thing), the files would be logs/watchdog-callback-heartbeat.1359 logs/watchdog-callback-dialup.1359 (These are both instances of the watchdog-callback type, which is what would be specified on the Mutex directive.) Is there any reason we can't invert the arg order, so that we have Mutex mutextype:name Resource [Resource ...] [OmitPid] Maybe it would be clearer if the optional OmitPid came before the list of mutexes? Of course, default could be assumed here. So the above becomes Mutex SysVSem Mutex file:/mnt/sesscachedir SSLSessionCache OmitPid (note the Resource tag can be the actual directive being mutexed, instead of an alt-name). Thoughts? I'm fine with putting the mechanism:dir first followed by a list of mutex type names. I'm not sure about where to put the OmitPid though. I guess you get used to either after a while. (Joe suggested Mutex name1,name2,name3 mechanism:dir; I didn't get around to splitting up the first arg to implement that.) In the ssl-cache example, the name of the mutex will be simply /mnt/sesscachedir/ssl-cache Does that meet the special SSLMutex requirement? Well, it's not strictly SSLMutex, understood that its a general capability but any other shared-resource that requires cross process/cross machine mutexing. The SSL session cache mutex is the only use case we have now. At any rate, I take that as a yes answer ;) (user somehow says omit-the-pid on the Mutex directive, case closed)
Re: svn commit: r883816 - in /httpd/httpd/trunk: include/util_mutex.h server/util_mutex.c
On Tue, Nov 24, 2009 at 2:50 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: traw...@apache.org wrote: --- httpd/httpd/trunk/include/util_mutex.h (original) +++ httpd/httpd/trunk/include/util_mutex.h Tue Nov 24 19:06:16 2009 @@ -99,9 +99,9 @@ const char **mutexfile); /* private function to process the Mutex directive */ -AP_DECLARE(const char *) ap_set_mutex(cmd_parms *cmd, void *dummy, - const char *typelist, - const char *mechfile); If this is a public function (and it is named as one) please revert ;-) I used ap_set_name_virtual_host() as an example due to its unfortunate locality to Mutex in the list of directives in server/core.c. It is also an undecorated const char *ap_set_name_virtual_host(). Many if not all other functions which handle directives and which are not implemented in the same file as the directive declaration also have the ap_ prefix, so I don't follow you on the public aspect. But most of these other functions are declared with AP_DECLARE_NONSTD(). That seems to be appropriate for ap_set_mutex(), ap_set_name_virtual_host(), and perhaps others. Is that the fix?
Re: svn commit: r883540 - in /httpd/httpd/trunk: ./ build/ docs/conf/ docs/conf/extra/ include/ modules/aaa/ modules/core/ modules/examples/ modules/generators/ modules/ldap/ modules/mappers/ module
Jeff Trawick wrote: no, even I could understand I fixed it by hardcoding logs when DEFAULT_REL_RUNTIMEDIR isn't defined. This works for me at least. (mpm_default.h won't be found on Unix without build changes, and we want to minimize affinity with any particular MPM anyway.) I find that odd since I see it in the mpm_default.h files under all the various mpms (worker/simple/event). I left a note to clean up access to DEFAULT_REL_RUNTIMEDIR for some other rainy day. Rainy days are for such things. I see wrowe's comment post your reply, do you feel like a ping-pong ball yet? ;-) I thank you for your prompt attention to this matter, Gregg
Re: svn commit: r883816 - in /httpd/httpd/trunk: include/util_mutex.h server/util_mutex.c
William A. Rowe Jr. wrote: traw...@apache.org wrote: --- httpd/httpd/trunk/include/util_mutex.h (original) +++ httpd/httpd/trunk/include/util_mutex.h Tue Nov 24 19:06:16 2009 @@ -99,9 +99,9 @@ const char **mutexfile); /* private function to process the Mutex directive */ -AP_DECLARE(const char *) ap_set_mutex(cmd_parms *cmd, void *dummy, - const char *typelist, - const char *mechfile); If this is a public function (and it is named as one) please revert ;-) Um, it appears to have been introduced in r883540 only yesterday, and this was a revert (to private). Regarding r883540 itself, I've just taken a look at it. It seems to enforce the same mutex type on all modules that use a mutex. Can't see an obvious reason not to do that, but it might merit discussion on-list. For example, maybe someone has a good reason to use different mutex types for a proc mutex and a global mutex? -- Nick Kew
Re: svn commit: r883816 - in /httpd/httpd/trunk: include/util_mutex.h server/util_mutex.c
Jeff Trawick wrote: Many if not all other functions which handle directives and which are not implemented in the same file as the directive declaration also have the ap_ prefix, so I don't follow you on the public aspect. s/public/meant to be exported/ But most of these other functions are declared with AP_DECLARE_NONSTD(). That seems to be appropriate for ap_set_mutex(), ap_set_name_virtual_host(), and perhaps others. AP_DECLARE_NONSTD() really has one goal, which is offering variable arg lists. A secondary effect is to use a pure C calling convention, the sort of thing you might need for some registered callbacks (e.g. atexit, etc). Otherwise AP_DECLARE() would seem fine. I think the registered cmd handler might need to be NONSTD.
Re: svn commit: r883816 - in /httpd/httpd/trunk: include/util_mutex.h server/util_mutex.c
Nick Kew wrote: Regarding r883540 itself, I've just taken a look at it. It seems to enforce the same mutex type on all modules that use a mutex. Can't see an obvious reason not to do that, but it might merit discussion on-list. For example, maybe someone has a good reason to use different mutex types for a proc mutex and a global mutex? This permits your desired feature, please reread the thread between Jeff and I, he explained it really well.
Re: svn commit: r883540 - in /httpd/httpd/trunk: ./ build/ docs/conf/ docs/conf/extra/ include/ modules/aaa/ modules/core/ modules/examples/ modules/generators/ modules/ldap/ modules/mappers/ module
On Tue, Nov 24, 2009 at 3:12 PM, Gregg L. Smith li...@glewis.com wrote: Jeff Trawick wrote: (mpm_default.h won't be found on Unix without build changes, and we want to minimize affinity with any particular MPM anyway.) I find that odd since I see it in the mpm_default.h files under all the various mpms (worker/simple/event). The other MPMs use that setting internally, but don't define that setting. I see wrowe's comment post your reply, do you feel like a ping-pong ball yet? ;-) yes!
Re: svn commit: r883712 - /httpd/httpd/trunk/docs/manual/mod/core.xml
On Tue, Nov 24, 2009 at 3:00 PM, Jeff Trawick traw...@gmail.com wrote: On Tue, Nov 24, 2009 at 1:58 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Jeff Trawick wrote: What about an optional third argument to Mutex to indicate that the pid should be omitted? Mutex default sysvsem Mutex ssl-cache file:/mnt/sesscachedir OmitPid etc. That seems sensible, but I'm left wondering how many different naming conventions we can fit on one directive line. Perhaps bOmitPID instead ;-) This really becomes harder to follow than the existing multiple-syntaxes. Is there any reason not to name these mutexes in MixedCase? I like having the mutex type name as of the filename, and mixed case filenames are unexpected. Beyond that, MixedCase and the . before the pid suffix don't totally resolve readability. Modules like mod_watchdog with multi-instance mutexes provide an instance string which gets inserted as - string prior to the . pid suffix. If the watchdog names are heartbeat and dialup (wild guess; I didn't look closely or try to configure the thing), the files would be logs/watchdog-callback-heartbeat.1359 logs/watchdog-callback-dialup.1359 (These are both instances of the watchdog-callback type, which is what would be specified on the Mutex directive.) Is there any reason we can't invert the arg order, so that we have Mutex mutextype:name Resource [Resource ...] [OmitPid] Maybe it would be clearer if the optional OmitPid came before the list of mutexes? Of course, default could be assumed here. So the above becomes Mutex SysVSem Mutex file:/mnt/sesscachedir SSLSessionCache OmitPid (note the Resource tag can be the actual directive being mutexed, instead of an alt-name). Thoughts? I'm fine with putting the mechanism:dir first followed by a list of mutex type names. I'm not sure about where to put the OmitPid though. I guess you get used to either after a while. (Joe suggested Mutex name1,name2,name3 mechanism:dir; I didn't get around to splitting up the first arg to implement that.) In the ssl-cache example, the name of the mutex will be simply /mnt/sesscachedir/ssl-cache In case it wasn't clear, I'm very eager to clear up/re-implement/etc. any remaining details of this lovely mess, but I'm hoping that more minds will show up and then converge to something (anything) on the more subjective aspects.
