Re: modules registry
...and in the form the Apache version checkboxes aren't shown properly leaving you without a confirmation on whether the database has stored this piece of information -- Massimo On 06.01.2012 18:40, Steve Rawlinson wrote: Hi, I've recently taken over maintenance of an apache module and want to update it's entry in the registry. I have a feeling the user signup is not working properly, and the 'forgot password' link definitely isn't. steve
Fwd: svn commit: r1228700 - in /httpd/httpd/trunk/docs: STATUS manual/mod/mod_heartbeat.xml manual/mod/mod_heartmonitor.xml manual/mod/mod_watchdog.xml manual/mod/mod_watchdog.xml.meta
Folks, I've put in some updates to the mod_heart* modules, taken from the README supplied with the modules and some perusal of the source code. I have not run these as I'm too lazy to set up the servers. Review would be appreciated, especially by the original authors (Cc), before backport to 2.4.x. Also added a doc file for mod_watchdog. Question for the docs folks: since this one is only of interest for consumption by other modules, how much documentation should we supply in the user-facing pages? I said this module defines programmatic hooks... do we need to define what the hook handler prototypes are? That's more like developer documentation. Thoughts? S. Begin forwarded message: From: scte...@apache.org Subject: svn commit: r1228700 - in /httpd/httpd/trunk/docs: STATUS manual/mod/mod_heartbeat.xml manual/mod/mod_heartmonitor.xml manual/mod/mod_watchdog.xml manual/mod/mod_watchdog.xml.meta Date: January 7, 2012 11:10:29 AM PST To: c...@httpd.apache.org Reply-To: dev@httpd.apache.org Author: sctemme Date: Sat Jan 7 19:10:28 2012 New Revision: 1228700 URL: http://svn.apache.org/viewvc?rev=1228700view=rev Log: Update heartbeat module documentation, add documentation for mod_watchdog Added: httpd/httpd/trunk/docs/manual/mod/mod_watchdog.xml (with props) httpd/httpd/trunk/docs/manual/mod/mod_watchdog.xml.meta Modified: httpd/httpd/trunk/docs/STATUS httpd/httpd/trunk/docs/manual/mod/mod_heartbeat.xml httpd/httpd/trunk/docs/manual/mod/mod_heartmonitor.xml Modified: httpd/httpd/trunk/docs/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/STATUS?rev=1228700r1=1228699r2=1228700view=diff == --- httpd/httpd/trunk/docs/STATUS (original) +++ httpd/httpd/trunk/docs/STATUS Sat Jan 7 19:10:28 2012 @@ -56,12 +56,8 @@ To Do List Start is in expr.xml, igalic is working on this - modules docs -- the follwing modules added since 2.2 lack documentation +- the following modules added since 2.2 lack documentation - mod_serf -- mod_watchdog -- mod_heartbeat -- mod_heartmonitor -- mod_lbmethod_heartbeat - mpm_simple the list may be incomplete maybe some of the modules will not be included in 2.4 Modified: httpd/httpd/trunk/docs/manual/mod/mod_heartbeat.xml URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_heartbeat.xml?rev=1228700r1=1228699r2=1228700view=diff == --- httpd/httpd/trunk/docs/manual/mod/mod_heartbeat.xml (original) +++ httpd/httpd/trunk/docs/manual/mod/mod_heartbeat.xml Sat Jan 7 19:10:28 2012 @@ -35,21 +35,66 @@ that advertises the servers current conn will be running on a proxy server with modulemod_lbmethod_heartbeat/module loaded, which allows directive module=mod_proxyProxyPass/directive to use the heartbeat emlbmethod/em inside of directive module=mod_proxyProxyPass/directive./p +p +modulemod_heartbeat/module itself is loaded on the origin server(s) that serve requests +through the proxy server(s). +/p + +note type=warning +To use modulemod_heartbeat/module, +modulemod_status/module and modulemod_watchdog/module +must be either a static modules or, if a dynamic module, it must +be loaded before modulemod_heartbeat/module. +/note + /summary +section id=consuming +titleConsuming mod_heartbeat Output/title + p + Every 1 second, this module generates a single multicast UDP + packet, containing the number of busy and idle workers. The + packet is a simple ASCII format, similiar to GET query parameters + in HTTP. + /p + +exampletitleAn Example Packet/title +v=1amp;ready=75amp;busy=0 +/example + + p +Consumers should handle new variables besides busy and ready, +separated by 'amp;', being added in the future. + /p + +/section + +section id=miscellaneous +titleMiscellaneous/title +pThe interval of 1 seconds is controlled by the HEARTBEAT_INTERVAL +compile time define. This is not currently tunable at run time. To make +this module send the status packet more often, you must add to the +CFLAGS used to compile the module to include:/p +example-DHEARTBEAT_INTERVAL=3/example +pWould cause the broadcasts to be sent every 3 seconds./p +/section + directivesynopsis nameHeartbeatAddress/name -descriptionAddress to send heartbeat requests/description +descriptionMulticast address for heartbeat packets/description syntaxHeartbeatAddress varaddr:port/var/syntax defaultdisabled/default contextlistcontextserver config/context/contextlist usage -pThe directiveHeartbeatAddress/directive directive specifies the -address modulemod_heartbeat/module will send status information to. This -address will
Re: Fwd: svn commit: r1228700 - in /httpd/httpd/trunk/docs: STATUS manual/mod/mod_heartbeat.xml manual/mod/mod_heartmonitor.xml manual/mod/mod_watchdog.xml manual/mod/mod_watchdog.xml.meta
On 07.01.2012 20:22, Sander Temme wrote: Folks, I've put in some updates to the mod_heart* modules, taken from the README supplied with the modules and some perusal of the source code. I have not run these as I'm too lazy to set up the servers. Review would be appreciated, especially by the original authors (Cc), before backport to 2.4.x. I added some comments inline, just based on reading your docs. Also added a doc file for mod_watchdog. Question for the docs folks: since this one is only of interest for consumption by other modules, how much documentation should we supply in the user-facing pages? I said this module defines programmatic hooks... do we need to define what the hook handler prototypes are? That's more like developer documentation. Thoughts? I don't know about the history of similar decisions, but IMHO what you wrote is good enough for 2.4.0. Modified: httpd/httpd/trunk/docs/manual/mod/mod_heartbeat.xml URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_heartbeat.xml?rev=1228700r1=1228699r2=1228700view=diff == --- httpd/httpd/trunk/docs/manual/mod/mod_heartbeat.xml (original) +++ httpd/httpd/trunk/docs/manual/mod/mod_heartbeat.xml Sat Jan 7 19:10:28 2012 @@ -35,21 +35,66 @@ that advertises the servers current conn will be running on a proxy server withmodulemod_lbmethod_heartbeat/module loaded, which allows directive module=mod_proxyProxyPass/directive to use the heartbeatemlbmethod/em inside ofdirective module=mod_proxyProxyPass/directive./p +p +modulemod_heartbeat/module itself is loaded on the origin server(s) that serve requests +through the proxy server(s). +/p + +note type=warning +To usemodulemod_heartbeat/module, +modulemod_status/module andmodulemod_watchdog/module +must be either a static modules or, if a dynamic module, it must +be loaded beforemodulemod_heartbeat/module. +/note + /summary +section id=consuming +titleConsuming mod_heartbeat Output/title +p + Every 1 second, this module generates a single multicast UDP + packet, containing the number of busy and idle workers. The + packet is a simple ASCII format, similiar to GET query parameters + in HTTP. +/p + +exampletitleAn Example Packet/title +v=1amp;ready=75amp;busy=0 +/example + +p +Consumers should handle new variables besides busy and ready, +separated by 'amp;', being added in the future. +/p + +/section + +section id=miscellaneous +titleMiscellaneous/title +pThe interval of 1 seconds is controlled by the HEARTBEAT_INTERVAL +compile time define. This is not currently tunable at run time. To make +this module send the status packet more often, you must add to the +CFLAGS used to compile the module to include:/p +example-DHEARTBEAT_INTERVAL=3/example +pWould cause the broadcasts to be sent every 3 seconds./p +/section more often than 1 second does not match the example 3 seconds ;) I guess more often is not possible (if resolution is seconds), so it would be less often? More important: I think this is totally wrong. The define exists, but I couldn't find any place in the code, which is influenced by it. I *guess* it uses the global watchdog interval configured for mod_watchdog. directivesynopsis nameHeartbeatAddress/name -descriptionAddress to send heartbeat requests/description +descriptionMulticast address for heartbeat packets/description syntaxHeartbeatAddressvaraddr:port/var/syntax defaultdisabled/default contextlistcontextserver config/context/contextlist usage -pThedirectiveHeartbeatAddress/directive directive specifies the -addressmodulemod_heartbeat/module will send status information to. This -address will usually corrspond to a configureddirective -module=mod_heartmonitorHeartbeatListen/directive on a frontend -proxy system./p +pThedirectiveHeartbeatAddress/directive directive specifies the +multicast address to whichmodulemod_heartbeat/module will send +status information. This address will usually correspond to a configured +directive module=mod_heartmonitorHeartbeatListen/directive on a +frontend proxy system./p +example +HeartbeatAddress 239.0.0.1:27999 +/example /usage /directivesynopsis Should we note, that Multicast needs to be enabled on both notes and routing needs to be set up, so that the multicast packets from the origin server can reach the proxy? On the one hand it is obvious, on the other hand not unlikely to be the typical first problem people run into. Modified: httpd/httpd/trunk/docs/manual/mod/mod_heartmonitor.xml URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_heartmonitor.xml?rev=1228700r1=1228699r2=1228700view=diff == --- httpd/httpd/trunk/docs/manual/mod/mod_heartmonitor.xml (original) +++ httpd/httpd/trunk/docs/manual/mod/mod_heartmonitor.xml Sat Jan 7
Re: Build-Warnings httpd 2.4.x Visual Studio 10, 32 Bit
Patches: maybe I'll have time, as it most are from one file.
root@x105:[/data/prj/httpd-2.3.16-beta]grep (W) nohup.out
util_expr_eval.c, line 1551.7: 1506-196 (W) Initialization between types
const void* and const char*(*)(struct {...}*,const void*) is not
allowed.
util_expr_eval.c, line 1552.7: 1506-196 (W) Initialization between types
const void* and const char*(*)(struct {...}*,const void*) is not
allowed.
util_expr_eval.c, line 1553.7: 1506-196 (W) Initialization between types
const void* and const char*(*)(struct {...}*,const void*) is not
allowed.
util_expr_eval.c, line 1554.7: 1506-196 (W) Initialization between types
const void* and const char*(*)(struct {...}*,const void*) is not
allowed.
util_expr_eval.c, line 1559.7: 1506-196 (W) Initialization between types
const void* and const char*(*)(struct {...}*,const void*,const char*)
is not allowed.
util_expr_eval.c, line 1560.7: 1506-196 (W) Initialization between types
const void* and const char*(*)(struct {...}*,const void*,const char*)
is not allowed.
util_expr_eval.c, line 1561.7: 1506-196 (W) Initialization between types
const void* and const char*(*)(struct {...}*,const void*,const char*)
is not allowed.
util_expr_eval.c, line 1562.7: 1506-196 (W) Initialization between types
const void* and const char*(*)(struct {...}*,const void*,const char*)
is not allowed.
util_expr_eval.c, line 1564.7: 1506-196 (W) Initialization between types
const void* and const char*(*)(struct {...}*,const void*,const char*)
is not allowed.
util_expr_eval.c, line 1565.7: 1506-196 (W) Initialization between types
const void* and const char*(*)(struct {...}*,const void*,const char*)
is not allowed.
util_expr_eval.c, line 1566.7: 1506-196 (W) Initialization between types
const void* and const char*(*)(struct {...}*,const void*,const char*)
is not allowed.
util_expr_eval.c, line 1567.7: 1506-196 (W) Initialization between types
const void* and const char*(*)(struct {...}*,const void*,const char*)
is not allowed.
util_expr_eval.c, line 1568.7: 1506-196 (W) Initialization between types
const void* and const char*(*)(struct {...}*,const void*,const char*)
is not allowed.
util_expr_eval.c, line 1569.7: 1506-196 (W) Initialization between types
const void* and const char*(*)(struct {...}*,const void*,const char*)
is not allowed.
util_expr_eval.c, line 1570.7: 1506-196 (W) Initialization between types
const void* and const char*(*)(struct {...}*,const void*,const char*)
is not allowed.
util_expr_eval.c, line 1571.7: 1506-196 (W) Initialization between types
const void* and const char*(*)(struct {...}*,const void*,char*) is not
allowed.
util_expr_eval.c, line 1572.7: 1506-196 (W) Initialization between types
const void* and const char*(*)(struct {...}*,const void*,char*) is not
allowed.
util_expr_eval.c, line 1578.7: 1506-196 (W) Initialization between types
const void* and int(*)(struct {...}*,const void*,const char*) is not
allowed.
util_expr_eval.c, line 1579.7: 1506-196 (W) Initialization between types
const void* and int(*)(struct {...}*,const void*,const char*) is not
allowed.
util_expr_eval.c, line 1580.7: 1506-196 (W) Initialization between types
const void* and int(*)(struct {...}*,const void*,const char*) is not
allowed.
util_expr_eval.c, line 1581.7: 1506-196 (W) Initialization between types
const void* and int(*)(struct {...}*,const void*,const char*) is not
allowed.
util_expr_eval.c, line 1582.7: 1506-196 (W) Initialization between types
const void* and int(*)(struct {...}*,const void*,const char*) is not
allowed.
util_expr_eval.c, line 1583.7: 1506-196 (W) Initialization between types
const void* and int(*)(struct {...}*,const void*,const char*) is not
allowed.
util_expr_eval.c, line 1584.7: 1506-196 (W) Initialization between types
const void* and int(*)(struct {...}*,const void*,const char*) is not
allowed.
util_expr_eval.c, line 1585.7: 1506-196 (W) Initialization between types
const void* and int(*)(struct {...}*,const void*,const char*) is not
allowed.
util_expr_eval.c, line 1586.7: 1506-196 (W) Initialization between types
const void* and int(*)(struct {...}*,const void*,const char*) is not
allowed.
util_expr_eval.c, line 1587.7: 1506-196 (W) Initialization between types
const void* and int(*)(struct {...}*,const void*,const char*) is not
allowed.
util_expr_eval.c, line 1588.7: 1506-196 (W) Initialization between types
const void* and int(*)(struct {...}*,const void*,const char*) is not
allowed.
util_expr_eval.c, line 1589.7: 1506-196 (W) Initialization between types
const void* and int(*)(struct {...}*,const void*,const char*) is not
allowed.
util_expr_eval.c, line 1590.7: 1506-196 (W) Initialization between types
const void* and int(*)(struct {...}*,const void*,const char*) is not
allowed.
util_expr_eval.c, line 1591.7: 1506-196 (W) Initialization between types
const void* and int(*)(struct {...}*,const void*,const char*) is not
allowed.
util_expr_eval.c, line 1596.7: 1506-196 (W) Initialization between types
const void* and int(*)(struct {...}*,const
Re: svn commit: r1228700 - in /httpd/httpd/trunk/docs: STATUS manual/mod/mod_heartbeat.xml manual/mod/mod_heartmonitor.xml manual/mod/mod_watchdog.xml manual/mod/mod_watchdog.xml.meta
On Jan 7, 2012, at 1:08 PM, Rainer Jung wrote: hook handler prototypes are? That's more like developer documentation. Thoughts? I don't know about the history of similar decisions, but IMHO what you wrote is good enough for 2.4.0. Sounds good. +pThe interval of 1 seconds is controlled by the HEARTBEAT_INTERVAL +compile time define. This is not currently tunable at run time. To make +this module send the status packet more often, you must add to the +CFLAGS used to compile the module to include:/p +example-DHEARTBEAT_INTERVAL=3/example +pWould cause the broadcasts to be sent every 3 seconds./p +/section more often than 1 second does not match the example 3 seconds ;) I guess more often is not possible (if resolution is seconds), so it would be less often? More important: I think this is totally wrong. The define exists, but I couldn't find any place in the code, which is influenced by it. I *guess* it uses the global watchdog interval configured for mod_watchdog. Yep, it's not used. And WatchdogInterval in mod_watchdog should do the trick. Perhaps an early approach soon abandoned? Removed from docs. +pThedirectiveHeartbeatAddress/directive directive specifies the +multicast address to whichmodulemod_heartbeat/module will send +status information. This address will usually correspond to a configured +directive module=mod_heartmonitorHeartbeatListen/directive on a +frontend proxy system./p +example +HeartbeatAddress 239.0.0.1:27999 +/example /usage /directivesynopsis Should we note, that Multicast needs to be enabled on both notes and routing needs to be set up, so that the multicast packets from the origin server can reach the proxy? On the one hand it is obvious, on the other hand not unlikely to be the typical first problem people run into. I'm +1 on a note, but don't think we should tell the story on setting up IP Multicast. I omitted this mainly because I don't know the story well enough. Same for IPv6 address examples. +note type=warning +To usemodulemod_heartmonitor/module, +modulemod_status/module andmodulemod_watchdog/module +must be either a static modules or, if a dynamic module, it must +be loaded beforemodulemod_heartmonitor/module. +/note + ?? The README talks only about mod_status. I added mod_watchdog because mod_heart* has a hard dependency on its symbols. The mod_status dependency is not hard (mod_heartbeat loads without mod_status loaded, or with mod_status later in the config), but not having actually run this I don't know what more subtle issues might arise. Removed the orphaned singular it must be loaded. +example +HeartbeatListen 239.0.0.1:27999 +/example Same remark concerning the use of multicast as above. p This module is inactive until this directive is used./p /usage @@ -88,7 +100,7 @@ heartbeat requests to this server/descr pThedirectiveHeartbeatMaxServers/directive directive specifies the maximum number of servers that will be sending requests to this monitor server. It is used to control the size of the shared memory allocated -to store the heartbeat info./p +to store the heartbeat info whenmodulemod_slotmem_shm/module is in use./p Can this be changed using graceful restart? Only for flat file or also for shm? This gets set up in the post_config hook handler. I forget whether that gets called on a graceful, and have not analyzed whether the graceful restart case gets handled properly. I suspect this depends on the behaviour of the slotmem provider. In the file case, it seems that very few assumptions about the state of the world are made. Typo: corrspond - correspond Thank you. Additional info: it seems the data used for the load balancer is updated about every 5 seconds (define HM_UPDATE_SEC). More precisely it seems the heartmonitor is called by watchdog (with interval 0 seconds, but watchdog sleep at least 100ms), then updates the data from what is had previously read, then loops for 5 seconds reading new data and then returns to watchdog. This is done one one thread per child, but a mutex guarantees, that it only runs in one child at every time. Hope I'm right. I hope so, too. Furthermore the heartmonitor contains some additional code to handle POST requests directed to it and reading usage data directly from the POST body (in addition to the multicast method). I think the current info in mod_lbmethod_heartbeat.xml is confusing. It contains: I did not edit that doc. This modules load balancing algorithm favors servers with more ready (idle) capacity over time, but does not select the server with the most ready capacity every time. Servers that have 0 active clients are penalized, with the assumption that they are not fully initialized. As far as I can see in the code, it randomly chooses one of the idle origin server slots based on the last
Re: Function abuse/cpu wasteage?
apr_strncpy()?? In any case, there is a better way to do the check, and so I'll implement that. On Jan 5, 2012, at 4:24 PM, William A. Rowe Jr. wrote: modules\proxy\mod_proxy_balancer.c: PROXY_STRNCPY(bsel-s-lb pname, val); modules\proxy\mod_proxy_balancer.c: PROXY_STRNCPY(bsel-s-st icky_path, val); modules\proxy\mod_proxy_balancer.c: PROXY_STRNCPY(bsel-s-st icky, val); modules\proxy\mod_proxy_balancer.c: PROXY_STRNCPY(bsel-s -sticky_path, path); modules\proxy\mod_proxy.c:PROXY_STRNCPY(worker-s-route, val); modules\proxy\mod_proxy.c:PROXY_STRNCPY(worker-s-redirect, val); modules\proxy\mod_proxy.c:PROXY_STRNCPY(worker-s-flusher, val); modules\proxy\mod_proxy.c:PROXY_STRNCPY(balancer-s-sticky_path, val); modules\proxy\mod_proxy.c:PROXY_STRNCPY(balancer-s-sticky, val); modules\proxy\mod_proxy.c:PROXY_STRNCPY(balancer-s-sticky_path, pa th); modules\proxy\mod_proxy.c:PROXY_STRNCPY(conf-forward-s-name, proxy:forward); modules\proxy\mod_proxy.c: PROXY_STRNCPY(conf-forward-s-hostname, *); modules\proxy\mod_proxy.c:PROXY_STRNCPY(conf-forward-s-scheme, *); modules\proxy\mod_proxy.c:PROXY_STRNCPY(reverse-s-name, proxy :reverse); modules\proxy\mod_proxy.c:PROXY_STRNCPY(reverse-s-hostname, *); modules\proxy\mod_proxy.c:PROXY_STRNCPY(reverse-s-scheme, *); Where are the rv tests? If no rv tests were needed, then why waste all the extra strlen cycles, and not simply apr_cpystrn or apr_strncpy these instead?
