Re: Are we there yet?
I'd like to see us ship the bundled apr sources (well, I'd like to see NO bundled apr sources, but...) to include the APR_HAS_IPV6 for our windows apr.hw, given that all win platforms supported /today/ have support, and it works out quite well. Of course it's a deep intrinsic change in the build (something that didn't have to happen, but c'est la vie)... and would be incompatible for with older httpd's and some third party modules. To mark the auspicious occasion, what would folks think of shifting to apr 1.5 so that post-1.4 is the dividing line, for simplicities sake? Or, other suggestions about bridging that divide?
Re: Are we there yet?
On Fri, Dec 02, 2011 at 06:08:53PM -0600, William Rowe wrote: I suspect a single doc for mod_socache would probably be appropriate. The API docs are in a single doc, ap_socache.h. They are marked up using doxy syntax, if we want that in HTML can't we do that automagically using doxygen? Having to copy and paste that content into docs/ somewhere seems like a lot of effort with little benefit, and risks ambiguity and conflict with the header description. Which is authoritative? Regards, Joe
Re: Are we there yet?
On 03 Dec 2011, at 1:48 AM, Stefan Fritsch wrote: where are we WRT 2.4? Blockers: mod_proxy_scgi.c needs to be fixed for compilation with C89 (easy) The only blocker left in STATUS is this: * Modules that are not ready for production use must be removed. The same for modules without documentation. The mod_socache_* modules are now all documented. I also overhauled the caching guide. It previously consisted of a mix of information on HTTP caching and file handle / file content caching, which are two very different things, and the document only made sense if you understood HTTP caching already. The guide is now clearly divided into HTTP caching, socache caching and specialised caching (file handles, etc), and hopefully makes more sense. Regards, Graham --
Re: Are we there yet?
- Original Message - On Fri, Dec 02, 2011 at 06:08:53PM -0600, William Rowe wrote: I suspect a single doc for mod_socache would probably be appropriate. The API docs are in a single doc, ap_socache.h. They are marked up using doxy syntax, if we want that in HTML can't we do that automagically using doxygen? We can link to it, it resides here: http://ci.apache.org/projects/httpd/trunk/doxygen/index.html Having to copy and paste that content into docs/ somewhere seems like a lot of effort with little benefit, and risks ambiguity and conflict with the header description. Which is authoritative? Regards, Joe -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: Are we there yet?
On 12/6/2011 8:01 AM, Joe Orton wrote: On Fri, Dec 02, 2011 at 06:08:53PM -0600, William Rowe wrote: I suspect a single doc for mod_socache would probably be appropriate. The API docs are in a single doc, ap_socache.h. They are marked up using doxy syntax, if we want that in HTML can't we do that automagically using doxygen? Having to copy and paste that content into docs/ somewhere seems like a lot of effort with little benefit, and risks ambiguity and conflict with the header description. Which is authoritative? Not the API docs. The user docs explaining why to load the module, what it does, and how to configure it.
Re: Are we there yet?
- Original Message - On 12/4/2011 5:02 PM, Noel Butler wrote: On Sun, 2011-12-04 at 09:47 -0500, Jim Jagielski wrote: On Dec 2, 2011, at 6:48 PM, Stefan Fritsch wrote: Hi, where are we WRT 2.4? There seems to be a lot of renewed effort in getting 2.4/trunk is a really releasable state, which is all Goodness. Ideally, I'd like to release 2.4.0 before the end of the year, but starting off 2012 with a new httpd release also makes some sense as well. +1 for 2012, can't see too many admins upgrading to a new major version with mere weeks till festive season break, and in some countries, that's a long break. Then perhaps we've already arrived at 2.4.1 by the time they attack it. That's not exactly a bad thing. We want to push forward quickly. Just not rushed :) +1 - most admins won't install a .0 release anyway ;) i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: Are we there yet?
2.4.0 GA asap; 2.3.15 running fine for quite some Windows admins. On Apachelounge and related sites for a few weeks, no single issue. Only hard bugs reported: Rewrite P as I reported crashing Watchdog. Other ones: mod_fcgid has two serious issues (also in 2.2) see bugzilla. run in DOS box, not shutting down when closing window. On Monday 05/12/2011 at 09:39, Igor Galić wrote: - Original Message - On 12/4/2011 5:02 PM, Noel Butler wrote: On Sun, 2011-12-04 at 09:47 -0500, Jim Jagielski wrote: On Dec 2, 2011, at 6:48 PM, Stefan Fritsch wrote: Hi, where are we WRT 2.4? There seems to be a lot of renewed effort in getting 2.4/trunk is a really releasable state, which is all Goodness. Ideally, I'd like to release 2.4.0 before the end of the year, but starting off 2012 with a new httpd release also makes some sense as well. +1 for 2012, can't see too many admins upgrading to a new major version with mere weeks till festive season break, and in some countries, that's a long break. Then perhaps we've already arrived at 2.4.1 by the time they attack it. That's not exactly a bad thing. We want to push forward quickly. Just not rushed :) +1 - most admins won't install a .0 release anyway ;) i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: Are we there yet?
2.4.0 GA asap; 2.3.15 running fine for quite some Windows admins. On Apachelounge and related sites for a few weeks, no single issue. Only hard bugs reported: Rewrite P as I reported crashing Watchdog. Other ones: mod_fcgid has two serious issues (also in 2.2) see bugzilla. run in DOS box, not shutting down when closing window. On Monday 05/12/2011 at 09:39, Igor Galić wrote: - Original Message - On 12/4/2011 5:02 PM, Noel Butler wrote: On Sun, 2011-12-04 at 09:47 -0500, Jim Jagielski wrote: On Dec 2, 2011, at 6:48 PM, Stefan Fritsch wrote: Hi, where are we WRT 2.4? There seems to be a lot of renewed effort in getting 2.4/trunk is a really releasable state, which is all Goodness. Ideally, I'd like to release 2.4.0 before the end of the year, but starting off 2012 with a new httpd release also makes some sense as well. +1 for 2012, can't see too many admins upgrading to a new major version with mere weeks till festive season break, and in some countries, that's a long break. Then perhaps we've already arrived at 2.4.1 by the time they attack it. That's not exactly a bad thing. We want to push forward quickly. Just not rushed :) +1 - most admins won't install a .0 release anyway ;) i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: Are we there yet?
On Saturday 03 December 2011, William A. Rowe Jr. wrote: On 12/3/2011 1:32 AM, Gregg L. Smith wrote: On 12/2/2011 3:48 PM, Stefan Fritsch wrote: - the follwing modules added since 2.2 lack documentation - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb These are required for SSL AFIAK, they must stay! Mentioned in the mod_ssl docks should be sufficient IMHO. It isn't. Someone trimming their LoadModule lines will undoubtedly hit the wall trying to figure out why they couldn't just switch from memcache or dbm back to shmcb. Someone else will break there server simply removing unfamiliar modules from the list, particularly one which appears nowhere in the ASF HTTP Server module documents lists. This, and the mod_slotmem_* objects, really make lousy modules. Isn't the answer to this that all consumers of slotmem and socache should simply point to the mod_slotmem_*/mod_socache_* modules in the error message if the configured provider is not found? Then the user would immediately know that another module is required.
Re: Are we there yet?
On 4 Dec 2011, at 04:16, Gregg L. Smith wrote: What seems to have not made it in there .. I am not against adding them to mod_ssl, since I see no other use for these specific modules. mod_authn_socache is probably the first other module to benefit from separating out this functionality from mod_ssl. But I've also recommended it to a number of third-party developers who have asked about similar tasks. We don't know how many applications there are out there. -- Nick Kew
Re: Are we there yet?
On 12/4/2011 1:02 AM, Stefan Fritsch wrote: On Saturday 03 December 2011, William A. Rowe Jr. wrote: On 12/3/2011 1:32 AM, Gregg L. Smith wrote: On 12/2/2011 3:48 PM, Stefan Fritsch wrote: - the follwing modules added since 2.2 lack documentation - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb These are required for SSL AFIAK, they must stay! Mentioned in the mod_ssl docks should be sufficient IMHO. It isn't. Someone trimming their LoadModule lines will undoubtedly hit the wall trying to figure out why they couldn't just switch from memcache or dbm back to shmcb. Someone else will break there server simply removing unfamiliar modules from the list, particularly one which appears nowhere in the ASF HTTP Server module documents lists. This, and the mod_slotmem_* objects, really make lousy modules. Isn't the answer to this that all consumers of slotmem and socache should simply point to the mod_slotmem_*/mod_socache_* modules in the error message if the configured provider is not found? Then the user would immediately know that another module is required. +1, great idea
Re: Are we there yet?
On 04 Dec 2011, at 6:16 AM, Gregg L. Smith wrote: What seems to have not made it in there .. I am not against adding them to mod_ssl, since I see no other use for these specific modules. I see tonnes of uses for these modules. We already have mod_authn_socache in v2.4 right now, and mod_disk_cache was renamed mod_cache disk to pave the way for the existence of mod_cache_socache to replace mod_mem_cache. Having a general purpose key/value store interface is a very useful thing. I like that stuff has been ripped out of core and modularized , that is, what I believe, makes the 2.4 footprint so small, load what you need and nothing more. +1. Regards, Graham --
Re: Are we there yet?
On 04 Dec 2011, at 11:02 AM, Stefan Fritsch wrote: Isn't the answer to this that all consumers of slotmem and socache should simply point to the mod_slotmem_*/mod_socache_* modules in the error message if the configured provider is not found? Then the user would immediately know that another module is required. +1. Regards, Graham --
Re: Are we there yet?
On 04 Dec 2011, at 12:28 AM, William A. Rowe Jr. wrote: It isn't. Someone trimming their LoadModule lines will undoubtedly hit the wall trying to figure out why they couldn't just switch from memcache or dbm back to shmcb. Someone else will break there server simply removing unfamiliar modules from the list, particularly one which appears nowhere in the ASF HTTP Server module documents lists. This is definitely a problem, but the changes to the error messages should make it clear to end users what their course of action should be. We're a modular server, adding a module to get something is normal. This, and the mod_slotmem_* objects, really make lousy modules. I can understand wanting to extend socache and slotmem into much more complex or experimental backend stores. Extensibility is good. But for the time being, and for this fundamental set... can we please trash all 6 modules and add the code into core? It seems to me that even apreq extensions are in a more usable, documented state than these... and we refuse to incorporate it. I think we got things backwards. This is just moving the furniture though, it doesn't solve the core problem, which is that they need to be documented (and the API wrong-ness you've pointed out needs to be fixed). Regards, Graham --
Re: Are we there yet?
On Dec 3, 2011, at 1:30 PM, Graham Leggett wrote: On 03 Dec 2011, at 2:49 AM, William A. Rowe Jr. wrote: On the subject of logs-relative vs absolute, / should prevail, the colon prefix is unacceptable. On the subject of anonymous, Anonymous mappings are mappings of that area of the process's virtual memory backed by the swap space instead of by a file in the file system name space. In this respect an anonymous mapping is similar to malloc, and is used in some malloc implementations for certain allocations. However, anonymous mappings are not part of the POSIX standard, though implemented by almost all systems. - http://en.wikipedia.org/wiki/Mmap It's pretty obvious why that shm anonymous implementation is laughable, as well as unacceptable. But in fact, the none implementation appearsto suggest anonymous, already. To break this down into things to do to fix this, the way I read it is that anonymous in this implementation means put it in a file called anonymous, which is silly for the reasons above. Would it make sense to make it do this: * none : no persistent data (anonymous) * rel_name : $server_root/rel_name.slotmem * /abs_name : $abs_name.slotmem In other words the relative filename works like everywhere else in the server, and if you happen to use the name anonymous, you end up with a relative filename, which happens to be the previous behavior. If so, say the word, I can make it so. +1.
Re: Are we there yet?
On Dec 2, 2011, at 6:48 PM, Stefan Fritsch wrote: Hi, where are we WRT 2.4? There seems to be a lot of renewed effort in getting 2.4/trunk is a really releasable state, which is all Goodness. Ideally, I'd like to release 2.4.0 before the end of the year, but starting off 2012 with a new httpd release also makes some sense as well. With all the changes, I would like to have another 'beta' release simply to try to work out any remaining issues, but my fear is that this would also encourage a lot of rework rather than polishing (if you get my drift). So tagging as a RC puts us in the more correct state of mind.
Re: Are we there yet?
On Dec 2, 2011, at 7:08 PM, William A. Rowe Jr. wrote: I was reading http://httpd.apache.org/docs/trunk/mod/mod_slotmem_shm.html and am rather fluxored that the authors apparently don't know the definition of the word anonymous shared memory. And there is a brand new syntax if users want log-root-relative paths? Why would slotmem throw away 15 years of filename argument conventions? IMHO this must be fixed before we call it GA. Whether that happens before a 2.4.0 beta doesn't bother me. As you likely know, the origins of slotmem grew out of the httpd-proxy-scoreboard branch (~5.5 years ago) and I assume jfclere had reasons for his choice for how to setup naming of paths, etc... But that is water under the bridge; if we wish to fix that then instead of throwing insults hither and yon, a really good idea would be to make the suggestion that it be fixed based on history/consistency/etc... I see that Graham has suggested a course of action, and I +1'ed it; if Graham lacks the time, I will find some cycles to address and implement.
Re: Are we there yet?
- Original Message - On Dec 2, 2011, at 6:48 PM, Stefan Fritsch wrote: Hi, where are we WRT 2.4? There seems to be a lot of renewed effort in getting 2.4/trunk is a really releasable state, which is all Goodness. Ideally, I'd like to release 2.4.0 before the end of the year, but starting off 2012 with a new httpd release also makes some sense as well. With all the changes, I would like to have another 'beta' release simply to try to work out any remaining issues, but my fear is that this would also encourage a lot of rework rather than polishing (if you get my drift). So tagging as a RC puts us in the more correct state of mind. Well I was wondering what the difference is. I'd still suggest to get a beta out now and then start with RCs in two week rythm. Thoughts? -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: Are we there yet?
On Sun, 4 Dec 2011, Jim Jagielski wrote: There seems to be a lot of renewed effort in getting 2.4/trunk is a really releasable state, which is all Goodness. Ideally, I'd like to release 2.4.0 before the end of the year, but starting off 2012 with a new httpd release also makes some sense as well. I was kind of hoping for GA before Christmas... With all the changes, I would like to have another 'beta' release simply to try to work out any remaining issues, but my fear is that this would also encourage a lot of rework rather than polishing (if you get my drift). So tagging as a RC puts us in the more correct state of mind. +1 for a RC ASAP. Do you have time to RM again? Would we name that RC 2.4.0 or would we release 2.3.16 from the 2.4.x branch? We could also consider putting the focus more on polishing by making API changes and large refactorings review-then-commit. Probably with the exception of the proxy/slotmem plans that were already put forward on the list. I would also like to know what more people think about the error message tag thing? AAUI Rich, Graham, and myself are for including it in 2.4 now, while Nick prefers to wait. If we decide to wait, it should maybe be reverted from trunk, too, to make merging of commits to 2.4 easier.
Re: Are we there yet?
On 04 Dec 2011, at 5:01 PM, Jim Jagielski wrote:
As you likely know, the origins of slotmem grew out of the
httpd-proxy-scoreboard
branch (~5.5 years ago) and I assume jfclere had reasons for his choice
for how to setup naming of paths, etc... But that is water under the
bridge; if we wish to fix that then instead of throwing insults hither and
yon, a really good idea would be to make the suggestion that it be
fixed based on history/consistency/etc...
I see that Graham has suggested a course of action, and I +1'ed
it; if Graham lacks the time, I will find some cycles to address
and implement.
I currently have this, which compiles but still needs to be tested. Busy this
afternoon, so if someone can take a look and see whether this works it would
help me. store_filename() seems sane, but the look up existing segment stuff
needs to be checked that it matches correctly.
Index: modules/slotmem/mod_slotmem_shm.c
===
--- modules/slotmem/mod_slotmem_shm.c (revision 1210009)
+++ modules/slotmem/mod_slotmem_shm.c (working copy)
@@ -119,29 +119,24 @@
* Persist the slotmem in a file
* slotmem name and file name.
* none : no persistent data
- * anonymous : $server_root/logs/anonymous.slotmem
- * :rel_name : $server_root/logs/rel_name.slotmem
- * abs_name : $abs_name.slotmem
+ * rel_name : $server_root/rel_name
+ * /abs_name : $abs_name
*
*/
static const char *store_filename(apr_pool_t *pool, const char *slotmemname)
{
const char *storename;
const char *fname;
-if (strcasecmp(slotmemname, none) == 0)
+if (strcasecmp(slotmemname, none) == 0) {
return NULL;
-else if (strcasecmp(slotmemname, anonymous) == 0)
-fname = ap_server_root_relative(pool, logs/anonymous);
-else if (slotmemname[0] == ':') {
-const char *tmpname;
-tmpname = apr_pstrcat(pool, logs/, slotmemname[1], NULL);
-fname = ap_server_root_relative(pool, tmpname);
}
+else if (slotmemname[0] != '/') {
+fname = ap_server_root_relative(pool, slotmemname);
+}
else {
fname = slotmemname;
}
-storename = apr_pstrcat(pool, fname, .slotmem, NULL);
-return storename;
+return fname;
}
static void store_slotmem(ap_slotmem_instance_t *slotmem)
@@ -269,14 +264,15 @@
(item_num * sizeof(char)) + basesize;
apr_status_t rv;
-if (gpool == NULL)
+if (gpool == NULL) {
return APR_ENOSHMAVAIL;
+}
if (name) {
-if (name[0] == ':') {
-fname = name;
+if (name[0] != '/') {
+fname = ap_server_root_relative(pool, name);
}
else {
-fname = ap_server_root_relative(pool, name);
+fname = name;
}
/* first try to attach to existing slotmem */
@@ -295,11 +291,11 @@
}
}
else {
-fname = anonymous;
+fname = none;
}
/* first try to attach to existing shared memory */
-fbased = (name name[0] != ':');
+fbased = (name != NULL);
if (fbased) {
rv = apr_shm_attach(shm, fname, gpool);
}
Regards,
Graham
--
Re: Are we there yet?
On 04 Dec 2011, at 5:41 PM, Stefan Fritsch wrote: I was kind of hoping for GA before Christmas... +1. We could also consider putting the focus more on polishing by making API changes and large refactorings review-then-commit. Probably with the exception of the proxy/slotmem plans that were already put forward on the list. The only thing we should be changing right now apart from low hanging fruit is API changes, if an API is genuinely broken it needs to get fixed. We need to draw a line though, mod_proxy could do with a serious refactor but that has missed the boat from v2.4 - what is important though it to make sure that during the life of httpd v2.4, backporting isn't that onerous to do. I would also like to know what more people think about the error message tag thing? AAUI Rich, Graham, and myself are for including it in 2.4 now, while Nick prefers to wait. If we decide to wait, it should maybe be reverted from trunk, too, to make merging of commits to 2.4 easier. I think it should go into both, or none at all. Backporting changes will becomes a serious pain if something as widely deployed as log messages are different between v2.4 and trunk. Regards, Graham --
Re: Are we there yet?
On 04 Dec 2011, at 3:27 AM, Nick Kew wrote: We have http://httpd.apache.org/docs/2.4/socache.html In the absence of actual module pages, a solution would be to create the URLs for them, with redirection to that page. Add appropriate links and they're well-documented for someone reading TFM. +1. Can we please do no such thing? Maybe for 2.6 they could take on something more like the DBD architecture: a generic mod_socache and different backends with a different load mechanism. If anyone feels inspired to hack it. +1. Regards, Graham --
Re: Are we there yet?
On 12/03/2011 08:32 AM, Gregg L. Smith wrote: On 12/2/2011 3:48 PM, Stefan Fritsch wrote: - modules docs - the follwing modules added since 2.2 lack documentation - mod_watchdog - mod_heartbeat - mod_heartmonitor - mod_lbmethod_heartbeat I vote these off the Windows boat, mod_watchdog crashes the child processes on Win and is basically required for the rest of them, in a round about way. I even asked Steffen at Apache Lounge to check it for me. I have more detail, but I have spoken up about it long ago and I have seen no movement from original author. However, if someone wants to know, feel free to ask. If its crashing it should be fixed. There is nothing in that module that would crash 'by-design' so its probably some bug introduced later after my initial commit. Give me couple of days and I'll fix the module, and write some docs. Regards -- ^TM
Re: Are we there yet?
On Dec 4, 2011, at 10:41 AM, Stefan Fritsch wrote: On Sun, 4 Dec 2011, Jim Jagielski wrote: There seems to be a lot of renewed effort in getting 2.4/trunk is a really releasable state, which is all Goodness. Ideally, I'd like to release 2.4.0 before the end of the year, but starting off 2012 with a new httpd release also makes some sense as well. I was kind of hoping for GA before Christmas... With all the changes, I would like to have another 'beta' release simply to try to work out any remaining issues, but my fear is that this would also encourage a lot of rework rather than polishing (if you get my drift). So tagging as a RC puts us in the more correct state of mind. +1 for a RC ASAP. Do you have time to RM again? Would we name that RC 2.4.0 or would we release 2.3.16 from the 2.4.x branch? We could also consider putting the focus more on polishing by making API changes and large refactorings review-then-commit. Probably with the exception of the proxy/slotmem plans that were already put forward on the list. I would also like to know what more people think about the error message tag thing? AAUI Rich, Graham, and myself are for including it in 2.4 now, while Nick prefers to wait. If we decide to wait, it should maybe be reverted from trunk, too, to make merging of commits to 2.4 easier. Let's be honest... if we punt to trunk, it'll be another several years before people see it. Let's do it now. Let's make 2.4 the best it can be... I also need to look at the event changes as well in trunk to see if they are in 2.4.0 as well (or if they are something we could easily add post 2.4.0)... Let's shoot for an RC1 this week. I'll RM.
Re: Are we there yet?
I'm +1 for committing as is and letting people test/patch
from there and then backporting ;)
On Dec 4, 2011, at 10:41 AM, Graham Leggett wrote:
On 04 Dec 2011, at 5:01 PM, Jim Jagielski wrote:
As you likely know, the origins of slotmem grew out of the
httpd-proxy-scoreboard
branch (~5.5 years ago) and I assume jfclere had reasons for his choice
for how to setup naming of paths, etc... But that is water under the
bridge; if we wish to fix that then instead of throwing insults hither and
yon, a really good idea would be to make the suggestion that it be
fixed based on history/consistency/etc...
I see that Graham has suggested a course of action, and I +1'ed
it; if Graham lacks the time, I will find some cycles to address
and implement.
I currently have this, which compiles but still needs to be tested. Busy this
afternoon, so if someone can take a look and see whether this works it would
help me. store_filename() seems sane, but the look up existing segment
stuff needs to be checked that it matches correctly.
Index: modules/slotmem/mod_slotmem_shm.c
===
--- modules/slotmem/mod_slotmem_shm.c (revision 1210009)
+++ modules/slotmem/mod_slotmem_shm.c (working copy)
@@ -119,29 +119,24 @@
* Persist the slotmem in a file
* slotmem name and file name.
* none : no persistent data
- * anonymous : $server_root/logs/anonymous.slotmem
- * :rel_name : $server_root/logs/rel_name.slotmem
- * abs_name : $abs_name.slotmem
+ * rel_name : $server_root/rel_name
+ * /abs_name : $abs_name
*
*/
static const char *store_filename(apr_pool_t *pool, const char *slotmemname)
{
const char *storename;
const char *fname;
-if (strcasecmp(slotmemname, none) == 0)
+if (strcasecmp(slotmemname, none) == 0) {
return NULL;
-else if (strcasecmp(slotmemname, anonymous) == 0)
-fname = ap_server_root_relative(pool, logs/anonymous);
-else if (slotmemname[0] == ':') {
-const char *tmpname;
-tmpname = apr_pstrcat(pool, logs/, slotmemname[1], NULL);
-fname = ap_server_root_relative(pool, tmpname);
}
+else if (slotmemname[0] != '/') {
+fname = ap_server_root_relative(pool, slotmemname);
+}
else {
fname = slotmemname;
}
-storename = apr_pstrcat(pool, fname, .slotmem, NULL);
-return storename;
+return fname;
}
static void store_slotmem(ap_slotmem_instance_t *slotmem)
@@ -269,14 +264,15 @@
(item_num * sizeof(char)) + basesize;
apr_status_t rv;
-if (gpool == NULL)
+if (gpool == NULL) {
return APR_ENOSHMAVAIL;
+}
if (name) {
-if (name[0] == ':') {
-fname = name;
+if (name[0] != '/') {
+fname = ap_server_root_relative(pool, name);
}
else {
-fname = ap_server_root_relative(pool, name);
+fname = name;
}
/* first try to attach to existing slotmem */
@@ -295,11 +291,11 @@
}
}
else {
-fname = anonymous;
+fname = none;
}
/* first try to attach to existing shared memory */
-fbased = (name name[0] != ':');
+fbased = (name != NULL);
if (fbased) {
rv = apr_shm_attach(shm, fname, gpool);
}
Regards,
Graham
--
Re: Are we there yet?
On Dec 4, 2011, at 10:52 AM, Graham Leggett wrote: On 04 Dec 2011, at 5:41 PM, Stefan Fritsch wrote: I was kind of hoping for GA before Christmas... +1. We could also consider putting the focus more on polishing by making API changes and large refactorings review-then-commit. Probably with the exception of the proxy/slotmem plans that were already put forward on the list. The only thing we should be changing right now apart from low hanging fruit is API changes, if an API is genuinely broken it needs to get fixed. We need to draw a line though, mod_proxy could do with a serious refactor but that has missed the boat from v2.4 - what is important though it to make sure that during the life of httpd v2.4, backporting isn't that onerous to do. ++1... What I've been working on re mod_proxy is ensuring that the API for 2.4.0 is enough to allow us to support that refactoring...
Re: Are we there yet?
On 12/04/2011 06:37 PM, Jim Jagielski wrote: Let's shoot for an RC1 this week. I'll RM. Do we have bundled apr/apr-util versions defined? Regards -- ^TM
Re: Are we there yet?
On 04 Dec 2011, at 8:03 PM, Mladen Turk wrote: Let's shoot for an RC1 this week. I'll RM. Do we have bundled apr/apr-util versions defined? Ideally we want apr-util v1.4.0, which is yet to be released. I've proposed to RM a release of apr-util this weekend or next week to the APR project and haven't had any objections, am still happy to do so. Regards, Graham --
Re: Are we there yet?
On 12/04/2011 07:25 PM, Graham Leggett wrote: On 04 Dec 2011, at 8:03 PM, Mladen Turk wrote: Let's shoot for an RC1 this week. I'll RM. Do we have bundled apr/apr-util versions defined? Ideally we want apr-util v1.4.0, which is yet to be released. I've proposed to RM a release of apr-util this weekend or next week to the APR project and haven't had any objections, am still happy to do so. So the lazy consensus rule applies. Feel free to cut the release. Regards -- ^TM
Re: Are we there yet?
On Dec 4, 2011, at 1:25 PM, Graham Leggett wrote: On 04 Dec 2011, at 8:03 PM, Mladen Turk wrote: Let's shoot for an RC1 this week. I'll RM. Do we have bundled apr/apr-util versions defined? Ideally we want apr-util v1.4.0, which is yet to be released. I've proposed to RM a release of apr-util this weekend or next week to the APR project and haven't had any objections, am still happy to do so. Yeah, apu-1.4.0 would be the best choice. With my APR hat on, +1 for the release ;)
Re: Are we there yet?
On Sunday 04 December 2011, Jim Jagielski wrote: I also need to look at the event changes as well in trunk to see if they are in 2.4.0 as well (or if they are something we could easily add post 2.4.0)... The event changes in trunk are not ready for 2.4, see http://mail-archives.apache.org/mod_mbox/httpd- dev/20.mbox/%3CCAHSOX_C872kk7HWxfaeiEsHQm_2QVJDYjBajkg5RXjaBtx4%2BJQ%40mail.gmail.com%3E But I think it should be possible to backport them post-GA.
Re: Are we there yet?
On 04 Dec 2011, at 7:38 PM, Jim Jagielski wrote: I'm +1 for committing as is and letting people test/patch from there and then backporting ;) Done in r1210261. Can you give it a try? Regards, Graham --
Re: Are we there yet?
On Sun, 2011-12-04 at 09:47 -0500, Jim Jagielski wrote: On Dec 2, 2011, at 6:48 PM, Stefan Fritsch wrote: Hi, where are we WRT 2.4? There seems to be a lot of renewed effort in getting 2.4/trunk is a really releasable state, which is all Goodness. Ideally, I'd like to release 2.4.0 before the end of the year, but starting off 2012 with a new httpd release also makes some sense as well. +1 for 2012, can't see too many admins upgrading to a new major version with mere weeks till festive season break, and in some countries, that's a long break. signature.asc Description: This is a digitally signed message part
Re: Are we there yet?
On Dec 4, 2011, at 5:29 PM, Graham Leggett wrote: On 04 Dec 2011, at 7:38 PM, Jim Jagielski wrote: I'm +1 for committing as is and letting people test/patch from there and then backporting ;) Done in r1210261. Can you give it a try? Thx. will do!
Re: Are we there yet?
On 12/4/2011 5:02 PM, Noel Butler wrote: On Sun, 2011-12-04 at 09:47 -0500, Jim Jagielski wrote: On Dec 2, 2011, at 6:48 PM, Stefan Fritsch wrote: Hi, where are we WRT 2.4? There seems to be a lot of renewed effort in getting 2.4/trunk is a really releasable state, which is all Goodness. Ideally, I'd like to release 2.4.0 before the end of the year, but starting off 2012 with a new httpd release also makes some sense as well. +1 for 2012, can't see too many admins upgrading to a new major version with mere weeks till festive season break, and in some countries, that's a long break. Then perhaps we've already arrived at 2.4.1 by the time they attack it. That's not exactly a bad thing. We want to push forward quickly. Just not rushed :)
Re: Are we there yet?
On 03 Dec 2011, at 1:48 AM, Stefan Fritsch wrote: Graham has suggested some more refactoring for mod_proxy*. Would certainly be nice but not a blocker. I have harvested the low hanging fruit from mod_proxy, the next bit of refactoring will take a while and shouldn't hold up v2.4. Regards, Graham --
Re: Are we there yet?
On 03 Dec 2011, at 9:32 AM, Gregg L. Smith wrote: - modules docs - the follwing modules added since 2.2 lack documentation - mod_watchdog - mod_heartbeat - mod_heartmonitor - mod_lbmethod_heartbeat I vote these off the Windows boat, mod_watchdog crashes the child processes on Win and is basically required for the rest of them, in a round about way. I even asked Steffen at Apache Lounge to check it for me. I have more detail, but I have spoken up about it long ago and I have seen no movement from original author. However, if someone wants to know, feel free to ask. +1. Regards, Graham --
Re: Are we there yet?
On 03 Dec 2011, at 2:49 AM, William A. Rowe Jr. wrote: On the subject of logs-relative vs absolute, / should prevail, the colon prefix is unacceptable. On the subject of anonymous, Anonymous mappings are mappings of that area of the process's virtual memory backed by the swap space instead of by a file in the file system name space. In this respect an anonymous mapping is similar to malloc, and is used in some malloc implementations for certain allocations. However, anonymous mappings are not part of the POSIX standard, though implemented by almost all systems. - http://en.wikipedia.org/wiki/Mmap It's pretty obvious why that shm anonymous implementation is laughable, as well as unacceptable. But in fact, the none implementation appearsto suggest anonymous, already. To break this down into things to do to fix this, the way I read it is that anonymous in this implementation means put it in a file called anonymous, which is silly for the reasons above. Would it make sense to make it do this: * none : no persistent data (anonymous) * rel_name : $server_root/rel_name.slotmem * /abs_name : $abs_name.slotmem In other words the relative filename works like everywhere else in the server, and if you happen to use the name anonymous, you end up with a relative filename, which happens to be the previous behavior. If so, say the word, I can make it so. Regards, Graham --
Re: Are we there yet?
On 12/3/2011 1:32 AM, Gregg L. Smith wrote: On 12/2/2011 3:48 PM, Stefan Fritsch wrote: - the follwing modules added since 2.2 lack documentation - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb These are required for SSL AFIAK, they must stay! Mentioned in the mod_ssl docks should be sufficient IMHO. It isn't. Someone trimming their LoadModule lines will undoubtedly hit the wall trying to figure out why they couldn't just switch from memcache or dbm back to shmcb. Someone else will break there server simply removing unfamiliar modules from the list, particularly one which appears nowhere in the ASF HTTP Server module documents lists. This, and the mod_slotmem_* objects, really make lousy modules. I can understand wanting to extend socache and slotmem into much more complex or experimental backend stores. Extensibility is good. But for the time being, and for this fundamental set... can we please trash all 6 modules and add the code into core? It seems to me that even apreq extensions are in a more usable, documented state than these... and we refuse to incorporate it. I think we got things backwards. Bill
Re: Are we there yet?
On 12/3/2011 12:30 PM, Graham Leggett wrote: On 03 Dec 2011, at 2:49 AM, William A. Rowe Jr. wrote: On the subject of logs-relative vs absolute, / should prevail, the colon prefix is unacceptable. On the subject of anonymous, Anonymous mappings are mappings of that area of the process's virtual memory backed by the swap space instead of by a file in the file system name space. In this respect an anonymous mapping is similar to malloc, and is used in some malloc implementations for certain allocations. However, anonymous mappings are not part of the POSIX standard, though implemented by almost all systems. - http://en.wikipedia.org/wiki/Mmap It's pretty obvious why that shm anonymous implementation is laughable, as well as unacceptable. But in fact, thenone implementation appearsto suggest anonymous, already. To break this down into things to do to fix this, the way I read it is that anonymous in this implementation means put it in a file called anonymous, which is silly for the reasons above. Would it make sense to make it do this: * none : no persistent data (anonymous) * rel_name : $server_root/rel_name.slotmem * /abs_name : $abs_name.slotmem In other words the relative filename works like everywhere else in the server, and if you happen to use the name anonymous, you end up with a relative filename, which happens to be the previous behavior. If so, say the word, I can make it so. That sounds sensible (where none triggers apr_shm's anon logic), and if you have the time, terrific. Do we need the API to be appending .slotmem for the user? Seems like overkill, nowhere else in httpd does that happen, AFAICT.
Re: Are we there yet?
On 3 Dec 2011, at 22:28, William A. Rowe Jr. wrote: On 12/3/2011 1:32 AM, Gregg L. Smith wrote: On 12/2/2011 3:48 PM, Stefan Fritsch wrote: - the follwing modules added since 2.2 lack documentation - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb These are required for SSL AFIAK, they must stay! Mentioned in the mod_ssl docks should be sufficient IMHO. It isn't. Someone trimming their LoadModule lines We have http://httpd.apache.org/docs/2.4/socache.html In the absence of actual module pages, a solution would be to create the URLs for them, with redirection to that page. Add appropriate links and they're well-documented for someone reading TFM. can we please trash all 6 modules and add the code into core? Can we please do no such thing? Maybe for 2.6 they could take on something more like the DBD architecture: a generic mod_socache and different backends with a different load mechanism. If anyone feels inspired to hack it. -- Nick Kew
Re: Are we there yet?
On 12/3/2011 2:28 PM, William A. Rowe Jr. wrote: On 12/3/2011 1:32 AM, Gregg L. Smith wrote: On 12/2/2011 3:48 PM, Stefan Fritsch wrote: - the follwing modules added since 2.2 lack documentation - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb These are required for SSL AFIAK, they must stay! Mentioned in the mod_ssl docks should be sufficient IMHO. It isn't. Someone trimming their LoadModule lines will undoubtedly hit the wall trying to figure out why they couldn't just switch from memcache or dbm back to shmcb. Someone else will break there server simply removing unfamiliar modules from the list, particularly one which appears nowhere in the ASF HTTP Server module documents lists. Which is why I said mention them in the mod_ssl docs Say under the SSLSessionCache Directive For dbm, add a note that mod_socache_dbm is required. for .. well ... I see shm .. assuming shmdb tho I use and have configured as shmdb, that mod_socache_shmdb is required .. etc. I see nothing for memcache .. so looks like this needs some updating before GA However I am looking at the trunk docs ... since 2.4 is not online yet .. in the URL I assume they will be eventually be Cheers, Gregg
Re: Are we there yet?
On 12/3/2011 7:54 PM, Gregg L. Smith wrote: On 12/3/2011 2:28 PM, William A. Rowe Jr. wrote: On 12/3/2011 1:32 AM, Gregg L. Smith wrote: On 12/2/2011 3:48 PM, Stefan Fritsch wrote: - the follwing modules added since 2.2 lack documentation - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb These are required for SSL AFIAK, they must stay! Mentioned in the mod_ssl docks should be sufficient IMHO. It isn't. Someone trimming their LoadModule lines will undoubtedly hit the wall trying to figure out why they couldn't just switch from memcache or dbm back to shmcb. Someone else will break there server simply removing unfamiliar modules from the list, particularly one which appears nowhere in the ASF HTTP Server module documents lists. Which is why I said mention them in the mod_ssl docs Say under the SSLSessionCache Directive For dbm, add a note that mod_socache_dbm is required. for .. well ... I see shm .. assuming shmdb tho I use and have configured as shmdb, that mod_socache_shmdb is required .. etc. I see nothing for memcache .. so looks like this needs some updating before GA What seems to have not made it in there .. I am not against adding them to mod_ssl, since I see no other use for these specific modules. I like that stuff has been ripped out of core and modularized , that is, what I believe, makes the 2.4 footprint so small, load what you need and nothing more. Cheers, Gregg
Re: Are we there yet?
On 12/2/2011 5:48 PM, Stefan Fritsch wrote: Hi, where are we WRT 2.4? Blockers: mod_proxy_scgi.c needs to be fixed for compilation with C89 (easy) The only blocker left in STATUS is this: * Modules that are not ready for production use must be removed. The same for modules without documentation. I think we have already removed the obvious candidates WRT maturity. About documentation, docs/STATUS has this: - modules docs - the follwing modules added since 2.2 lack documentation - mod_watchdog - mod_heartbeat - mod_heartmonitor - mod_lbmethod_heartbeat - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb Do we want to remove any of these modules? I suspect a single doc for mod_socache would probably be appropriate. I was reading http://httpd.apache.org/docs/trunk/mod/mod_slotmem_shm.html and am rather fluxored that the authors apparently don't know the definition of the word anonymous shared memory. And there is a brand new syntax if users want log-root-relative paths? Why would slotmem throw away 15 years of filename argument conventions? IMHO this must be fixed before we call it GA. Whether that happens before a 2.4.0 beta doesn't bother me.
Re: Are we there yet?
On 12/2/2011 6:08 PM, William A. Rowe Jr. wrote: On 12/2/2011 5:48 PM, Stefan Fritsch wrote: Hi, where are we WRT 2.4? Blockers: mod_proxy_scgi.c needs to be fixed for compilation with C89 (easy) The only blocker left in STATUS is this: * Modules that are not ready for production use must be removed. The same for modules without documentation. I think we have already removed the obvious candidates WRT maturity. About documentation, docs/STATUS has this: - modules docs - the follwing modules added since 2.2 lack documentation - mod_watchdog - mod_heartbeat - mod_heartmonitor - mod_lbmethod_heartbeat - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb Do we want to remove any of these modules? I suspect a single doc for mod_socache would probably be appropriate. I was reading http://httpd.apache.org/docs/trunk/mod/mod_slotmem_shm.html and am rather fluxored that the authors apparently don't know the definition of the word anonymous shared memory. And there is a brand new syntax if users want log-root-relative paths? Why would slotmem throw away 15 years of filename argument conventions? IMHO this must be fixed before we call it GA. Whether that happens before a 2.4.0 beta doesn't bother me. [It also is a dev doc. There's nothing here for a user/administrator to understand why this module exists.]
Re: Are we there yet?
On 12/2/2011 6:10 PM, William A. Rowe Jr. wrote: On 12/2/2011 6:08 PM, William A. Rowe Jr. wrote: On 12/2/2011 5:48 PM, Stefan Fritsch wrote: Hi, where are we WRT 2.4? Blockers: mod_proxy_scgi.c needs to be fixed for compilation with C89 (easy) The only blocker left in STATUS is this: * Modules that are not ready for production use must be removed. The same for modules without documentation. I think we have already removed the obvious candidates WRT maturity. About documentation, docs/STATUS has this: - modules docs - the follwing modules added since 2.2 lack documentation - mod_watchdog - mod_heartbeat - mod_heartmonitor - mod_lbmethod_heartbeat - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb Do we want to remove any of these modules? I suspect a single doc for mod_socache would probably be appropriate. I was reading http://httpd.apache.org/docs/trunk/mod/mod_slotmem_shm.html and am rather fluxored that the authors apparently don't know the definition of the word anonymous shared memory. And there is a brand new syntax if users want log-root-relative paths? Why would slotmem throw away 15 years of filename argument conventions? On the subject of logs-relative vs absolute, / should prevail, the colon prefix is unacceptable. On the subject of anonymous, Anonymous mappings are mappings of that area of the process's virtual memory backed by the swap space instead of by a file in the file system name space. In this respect an anonymous mapping is similar to malloc, and is used in some malloc implementations for certain allocations. However, anonymous mappings are not part of the POSIX standard, though implemented by almost all systems. - http://en.wikipedia.org/wiki/Mmap It's pretty obvious why that shm anonymous implementation is laughable, as well as unacceptable. But in fact, the none implementation appearsto suggest anonymous, already.
Re: Are we there yet?
On 12/2/2011 3:48 PM, Stefan Fritsch wrote: - modules docs - the follwing modules added since 2.2 lack documentation - mod_watchdog - mod_heartbeat - mod_heartmonitor - mod_lbmethod_heartbeat I vote these off the Windows boat, mod_watchdog crashes the child processes on Win and is basically required for the rest of them, in a round about way. I even asked Steffen at Apache Lounge to check it for me. I have more detail, but I have spoken up about it long ago and I have seen no movement from original author. However, if someone wants to know, feel free to ask. - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb These are required for SSL AFIAK, they must stay! Mentioned in the mod_ssl docks should be sufficient IMHO. Cheers, Gregg
