apache module metrics
Hi, Is there any module which gives me moulde metrics for each of the installed apache modules? For example, I need number of requests handled by mod_perl, no of requests rejected, request throughput etc. Is there any wayto get this information? Thanks, Ravi -- View this message in context: http://www.nabble.com/apache-module-metrics-tp21239638p21239638.html Sent from the Apache HTTP Server - Module Writers mailing list archive at Nabble.com.
Re: mod_fcgid license questions
On 31 Dec 2008, at 05:48, Roy T. Fielding wrote: Foes anyone have a sense of whether these would indeed require a CLA and SGA? They look like simple repairs to me. More importantly, if he thinks they are simple repairs and he is happy to see them Apache Licensed, then there is no need for a CLA or software grant. +1. This is in the same ballpark as third-party patches we routinely accept, e.g. from reports in bugzilla. -- Nick Kew
Configuration change for c...@httpd?
A while back, we made a configuration change to all of our commits@ (aka cvs@) lists across the foundation so that they are unmoderated. As a side-effect, it means that all posts require @apache.org addresses or you get a bounce back from MAILER-DAEMON. The side-effect of this (for at least Thunderbird and GMail) is that you can no longer hit 'reply all' to our commit emails without automatically also snarfing in c...@httpd as a recipient. So, if you hit 'reply all' and send from a non @apache.org address, you will get a nice bounce message each time you reply to the commit message unless you manually remove the recipient. From looking at the archives, I know that myself, Paul, Philip, and likely Jim have all hit this blowback to varying degrees over the last month. In light of this, Joe has suggested adding: To: undisclosed-recipients:; to headeradd for c...@httpd, overriding the normal To: c...@httpd.apache.org. That should prevent Reply-All from picking up the commit list, since there won't be anything in the To: or CC: fields for it to use. This should restore the ability to hit 'reply all' with Thunderbird and GMail for those of us who don't use @apache.org from addresses. Are there any objections to doing so? Thanks and have a healthy and happy new year with all of your friends and family. -- justin
Re: Configuration change for c...@httpd?
On 12/31/2008 03:48 PM, Justin Erenkrantz wrote: A while back, we made a configuration change to all of our commits@ (aka cvs@) lists across the foundation so that they are unmoderated. As a side-effect, it means that all posts require @apache.org addresses or you get a bounce back from MAILER-DAEMON. The side-effect of this (for at least Thunderbird and GMail) is that you can no longer hit 'reply all' to our commit emails without automatically also snarfing in c...@httpd as a recipient. So, if you hit 'reply all' and send from a non @apache.org address, you will get a nice bounce message each time you reply to the commit message unless you manually remove the recipient. From looking at the archives, I know that myself, Paul, Philip, and likely Jim have all hit this blowback to varying degrees over the last month. In light of this, Joe has suggested adding: To: undisclosed-recipients:; to headeradd for c...@httpd, overriding the normal To: c...@httpd.apache.org. That should prevent Reply-All from picking up the commit list, since there won't be anything in the To: or CC: fields for it to use. This should restore the ability to hit 'reply all' with Thunderbird and GMail for those of us who don't use @apache.org from addresses. Are there any objections to doing so? No. +1 to go ahead with this. Thanks and have a healthy and happy new year with all of your friends and family. -- justin The same to all of you and your families from me Regards Rüdiger
Re: Configuration change for c...@httpd?
On Dec 31, 2008, at 9:48 AM, Justin Erenkrantz wrote: From looking at the archives, I know that myself, Paul, Philip, and likely Jim have all hit this blowback to varying degrees over the last month. In light of this, Joe has suggested adding: To: undisclosed-recipients:; to headeradd for c...@httpd, overriding the normal To: c...@httpd.apache.org. That should prevent Reply-All from picking up the commit list, since there won't be anything in the To: or CC: fields for it to use. This should restore the ability to hit 'reply all' with Thunderbird and GMail for those of us who don't use @apache.org from addresses. Are there any objections to doing so? +1... So let it be written; so let it be done. Thanks and have a healthy and happy new year with all of your friends and family. -- justin +1 !! And Back atcha!
Re: Configuration change for c...@httpd?
On 12/31/2008 04:13 PM, Justin Erenkrantz wrote: On Wed, Dec 31, 2008 at 7:09 AM, Ruediger Pluem rpl...@apache.org wrote: No. +1 to go ahead with this. As the person who generally replies the most to commit messages, I was sort of wondering what you've been doing as I noticed that your replies all go to dev@ and don't have cvs@ in the 'to' line. *grin* I usually do only a 'reply to' and not a 'reply to all'. This works well in httpd land but backfires in APR land, where I usually use 'reply to all' and adjust the address list later on manually to my needs. Regards Rüdiger
Re: svn commit: r729059 - in /httpd/httpd/trunk/modules/mem: ./ .deps Makefile Makefile.in config5.m4 mod_plainmem.c mod_sharedmem.c modules.mk sharedmem_util.c sharedmem_util.h slotmem.h
On Dec 23, 2008, at 3:56 PM, Ruediger Pluem wrote: Style! Why no stack approach, but a queue approach for the list? Looking over, the orig impl had the list tucked away in an APR array... not sure when/why it was changed.
Re: mod_fcgid license questions
Hi -- On 31 Dec 2008, at 05:48, Roy T. Fielding wrote: Foes anyone have a sense of whether these would indeed require a CLA and SGA? They look like simple repairs to me. More importantly, if he thinks they are simple repairs and he is happy to see them Apache Licensed, then there is no need for a CLA or software grant. +1. This is in the same ballpark as third-party patches we routinely accept, e.g. from reports in bugzilla. OK, that sounds reasonable. I think we're just waiting to hear from one other person, then. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
slotmen API thoughts
Hi -- First of all, many thanks to Jim Jagielski, Jean-Frederic Clere, and Brian Akins for the slotmem API! Personally I think it would be great to see the mod_auth_digest and/or mod_proxy module gradually migrate toward using either the slotmem or socache APIs, as appropriate (and perhaps even the scoreboard itself?) A few initial thoughts, in two categories, specific and general. In the specific realm, I think mod_sharedmem.c should not be hard-coded to persist data into *.slotmem files in a logs/ directory. I know that we install some httpd instances with non-default layouts, e.g., the GNU layout where log files live under var/apache/log and other runtime files under var/apache/run. So I'd recommend that mod_sharedmem.c should support configuration directives that allow the admininstrator to choose (a) whether to persist data at all, (b) the filename format to use, and (c) where to store the data files. Also in the specific category, I feel we should probably move mod_slotmem.h up into include/, akin ap_socache.h and others. In the general category, I am somewhat unsure about the slotmem API design, especially in relation to the socache API. These thoughts came up because I began thinking about how to add additional slotmem providers and what these might look like. Could there be a slotmem provider that used a DB or ZooKeeper backend, for example? I came the conclusion that the API more or less prevented such options, because access to slots is performed through pointers to physical memory. The mem method returns such a pointer given an index. In fact, beyond the two existing providers -- unshared and shared memory -- I'm not at all sure what other kinds of things one could really do. I suppose one could write a mod_sharedmem variant that persisted data to a DB -- but then you're either duplicating all the code just to adjust the persistence mechanism, or adding some kind of sub-provider API to support different persistence choices. That led me to the following ideas, which I realize are somewhat radical alterations of the initial implementation. I'd be very happy to contribute to such modifications, though, if others felt they had value. In summary: - model API closely on socache API - include/ap_slotcache.h defines the following: - does not define internals of ap_slotcache_t; leave that to providers - no lock/unlock functions; leave that to callers but signal need for them with AP_SLOTCACHE_FLAG_NOTMPSAFE (parallel to AP_SOCACHE_FLAG_NOTMPSAFE, note NOTMPSAFE == not MP-safe) - slotcache provider methods: - create() - takes num_items and item_size - to be called during initial config pass, providers should not initialize or create mutexes here, etc. - init() - to be called during post-config pass, passed pconf pool, performs real initialization - destroy() - to be called from pconf pool cleanup - store()- takes index, value of item_size length - retrieve() - takes index and unsigned char* buffer to write into - reset()- takes index, clears value - maybe do(), or status(), akin to socache's status()? - AP_SLOTCACHE_PROVIDER_GROUP (slotcache) and AP_SLOTCACHE_PROVIDER_VERSION (0) - drop mod_slotmem.c and mod_plainmem.c (which, from one point of view, is something most programmers could do themselves pretty simply with just a big apr_palloc()) Finally (possibly in the bikeshed category), might I suggest a naming scheme that follows the socache format? Something like: include/ap_slotcache.h modules/cache/mod_slotcache_shm.c modules/cache/mod_slotcache_*.c The default provider would likely be mod_slotcache_shm.c which works pretty much like the existing mod_sharedmem.c, with config directives allowing the admin to control whether to persist data and where to put the resultant files, if desired. To my mind, the great advantage of having accessor methods like store(), retrieve(), and reset() instead of a mem() method is that a wide variety of providers can be envisioned. Some of these would be tuned for performance -- in particular, mod_slotcache_shm would work basically like the scoreboard, with slab of shared memory. It would use the NOTMPSAFE flag to indicate that callers need locking to ensure atomic reads/writes. Some users might want to add locking, but others, if they knew they didn't care about that, could skip it. That's how the scoreboard works at the moment, IIRC; it skips locking in favour of fast access. It could potentially migrate to this provider, as could the lbproxy stuff. (I'm not sure whether the currently-disable auth digest cache would work better with a slot or small-object key/value cache framework.) Other providers could offer a wide range of backend mechanisms, from DBM files to relational DBs to ZooKeeper and so forth. Thoughts? I know this is another of my long lists of helpful suggestions; my apologies
