Re: Error codes
On Wednesday 30 November 2011, Guenter Knauf wrote: Am 30.11.2011 01:51, schrieb William A. Rowe Jr.: On 11/29/2011 5:30 PM, Stefan Fritsch wrote: Currently my scripts produces: http://people.apache.org/~sf/error-msg-numbers.diff http://people.apache.org/~sf/error-msg-numbers.list This is level info and up, but that is easily changed. Everything from debug level up should be coded. Suggestion, should we allocate numeric ranges per-file, core vs add-on module, so that there is room for expansion? I am not sure that this is necessary. The error log lines already contain the module name or core. Actually I currently have two scripts, one that tries to identify where to add a number and adds AH, and another one that takes each AH and replaces it with the next free number. So programmers would only need to add AH and run the second script over the source file. The only disadvantage may be that in a list sorted by log number, messages by the same module would not appear next to each other. On the other hand, it should be easy to extend the script to also create a list sorted by module or source file name if that is useful. another suggestion - perhaps add a 3rd char: AHC - core AHM - module then we would have for both core and modules the whole range of error codes ... Sometimes we move code from the core to a module or vice versa. If the code is mostly unchanged, I would want to keep the error message number in this case. So best not encode that in the number, IMHO. If we ever hit the codes, we could either switch to hex or add another digit. Or would it be better to use 5 digits right away? Another thought: Would having the AH0815 numbers verbatim in the source actually hurt search engine users because they get hits on svn.apache.org, github, and whatever. Maybe a macro that hides the actual form would be better? #define APLOGNO(n) AH #n should do the trick. The source would then contain ap_log_error(..., APLOGNO(0815) foo went wrong, ...); which would not produce a hit for AH0815. Thoughts?
Re: Error codes
On Wednesday 30 November 2011, Mikhail T. wrote: On 29.11.2011 23:30, William A. Rowe Jr. wrote: But my point remains, that we allocate each module a block of some 50 codes, such that mod_aaa gets AHM-0049 and mod_aab gets 50-99, etc. How will 3rd-party modules be getting their blocks? One idea would be to have them use other prefixes than AH. But this may be a bad idea if we ever want the number to be used for other things.
Re: Error codes
ap_log_error(..., APLOGNO(0815) foo went wrong, ...); great idea on avoiding svn.a.o search hits.
Re: Error codes
On Wed, Nov 30, 2011 at 01:09, Stefan Fritsch s...@sfritsch.de wrote: On Wednesday 30 November 2011, Guenter Knauf wrote: Am 30.11.2011 01:51, schrieb William A. Rowe Jr.: On 11/29/2011 5:30 PM, Stefan Fritsch wrote: Currently my scripts produces: http://people.apache.org/~sf/error-msg-numbers.diff http://people.apache.org/~sf/error-msg-numbers.list This is level info and up, but that is easily changed. Everything from debug level up should be coded. Suggestion, should we allocate numeric ranges per-file, core vs add-on module, so that there is room for expansion? I am not sure that this is necessary. The error log lines already contain the module name or core. Actually I currently have two scripts, one that tries to identify where to add a number and adds AH, and another one that takes each AH and replaces it with the next free number. So programmers would only need to add AH and run the second script over the source file. The only disadvantage may be that in a list sorted by log number, messages by the same module would not appear next to each other. On the other hand, it should be easy to extend the script to also create a list sorted by module or source file name if that is useful. another suggestion - perhaps add a 3rd char: AHC - core AHM - module then we would have for both core and modules the whole range of error codes ... Sometimes we move code from the core to a module or vice versa. If the code is mostly unchanged, I would want to keep the error message number in this case. So best not encode that in the number, IMHO. If we ever hit the codes, we could either switch to hex or add another digit. Or would it be better to use 5 digits right away? Another thought: Would having the AH0815 numbers verbatim in the source actually hurt search engine users because they get hits on svn.apache.org, github, and whatever. Maybe a macro that hides the actual form would be better? #define APLOGNO(n) AH #n should do the trick. The source would then contain ap_log_error(..., APLOGNO(0815) foo went wrong, ...); which would not produce a hit for AH0815. Thoughts? Any reason *not* to use 5 digits? -- Sent from my toaster.
Re: svn commit: r1208384 - in /httpd/httpd/branches/2.4.x: CHANGES STATUS docs/manual/mod/mod_cache.xml modules/cache/cache_storage.c modules/cache/cache_storage.h modules/cache/mod_cache.c modules/ca
- Original Message - Author: minfrin Date: Wed Nov 30 11:21:43 2011 New Revision: 1208384 URL: http://svn.apache.org/viewvc?rev=1208384view=rev Log: mod_cache: Revert http://svn.apache.org/viewvc?view=revisionrevision=1070179 as per the following thread: http://www.gossamer-threads.com/lists/apache/dev/395830?do=post_view_threaded#395830 Modified: httpd/httpd/branches/2.4.x/CHANGES httpd/httpd/branches/2.4.x/STATUS Why only 2.4? 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: svn commit: r1070179 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_cache.xml modules/cache/cache_storage.c modules/cache/cache_storage.h modules/cache/mod_cache.c modules/cache/mod_cache.h
On 23 Nov 2011, at 1:15 PM, Graham Leggett wrote:
In order to make invalidation possible, we would need to add an invalidate()
function to the mod_cache provider, and keep AP_CACHE_INVALIDATE inside
ap_cache_status_e. Invalidation involves marking the entry as invalidated and
to be freshened on next hit, as opposed to deleted.
What I could do is back out the change, and make just the above API changes,
allowing us to backport this to v2.4 when we are ready.
This releases v2.4 to get on with it, and keeps the option open for us to fix
this properly at a future date in the v2.4 cycle when we're ready.
The change has been reverted on v2.4, and the following patch gives the API
changes that allow us to fix this in the v2.4 series:
Index: modules/cache/mod_cache.h
===
--- modules/cache/mod_cache.h (revision 1208384)
+++ modules/cache/mod_cache.h (working copy)
@@ -109,17 +109,20 @@
const char *urlkey);
int (*remove_url) (cache_handle_t *h, request_rec *r);
apr_status_t (*commit_entity)(cache_handle_t *h, request_rec *r);
+apr_status_t (*invalidate_entity)(cache_handle_t *h, request_rec *r);
} cache_provider;
typedef enum {
AP_CACHE_HIT,
AP_CACHE_REVALIDATE,
-AP_CACHE_MISS
+AP_CACHE_MISS,
+AP_CACHE_INVALIDATE
} ap_cache_status_e;
#define AP_CACHE_HIT_ENV cache-hit
#define AP_CACHE_REVALIDATE_ENV cache-revalidate
#define AP_CACHE_MISS_ENV cache-miss
+#define AP_CACHE_INVALIDATE_ENV cache-invalidate
#define AP_CACHE_STATUS_ENV cache-status
Index: modules/cache/mod_cache_disk.c
===
--- modules/cache/mod_cache_disk.c (revision 1208379)
+++ modules/cache/mod_cache_disk.c (working copy)
@@ -1325,6 +1325,11 @@
return APR_SUCCESS;
}
+static apr_status_t invalidate_entity(cache_handle_t *h, request_rec *r)
+{
+return APR_ENOTIMPL;
+}
+
static void *create_dir_config(apr_pool_t *p, char *dummy)
{
disk_cache_dir_conf *dconf = apr_pcalloc(p, sizeof(disk_cache_dir_conf));
@@ -1502,7 +1507,8 @@
create_entity,
open_entity,
remove_url,
-commit_entity
+commit_entity,
+invalidate_entity
};
static void disk_cache_register_hook(apr_pool_t *p)
Regards,
Graham
--
Re: svn commit: r1208384 - in /httpd/httpd/branches/2.4.x: CHANGES STATUS docs/manual/mod/mod_cache.xml modules/cache/cache_storage.c modules/cache/cache_storage.h modules/cache/mod_cache.c modules/ca
On 30 Nov 2011, at 1:26 PM, Igor Galić wrote: - Original Message - Author: minfrin Date: Wed Nov 30 11:21:43 2011 New Revision: 1208384 URL: http://svn.apache.org/viewvc?rev=1208384view=rev Log: mod_cache: Revert http://svn.apache.org/viewvc?view=revisionrevision=1070179 as per the following thread: http://www.gossamer-threads.com/lists/apache/dev/395830?do=post_view_threaded#395830 Modified: httpd/httpd/branches/2.4.x/CHANGES httpd/httpd/branches/2.4.x/STATUS Why only 2.4? Because the plan is to fix it on trunk, not revert it, as per the discussion in the thread quoted above. Regards, Graham --
Re: Error codes
On 11/30/2011 2:09 AM, Stefan Fritsch wrote: Another thought: Would having the AH0815 numbers verbatim in the source actually hurt search engine users because they get hits on svn.apache.org, github, and whatever. Maybe a macro that hides the actual form would be better? #define APLOGNO(n) AH #n should do the trick. The source would then contain ap_log_error(..., APLOGNO(0815) foo went wrong, ...); +1 To me, this is a must. This also adds a somewhat handy anchor when searching for log entries in code that may or may not span multiple lines. -- Daniel Ruggeri
Re: svn commit: r1208068 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c mod_proxy.h proxy_util.c
On Nov 29, 2011, at 4:25 PM, Igor Galić wrote:
--- httpd/httpd/trunk/modules/proxy/mod_proxy.h (original)
+++ httpd/httpd/trunk/modules/proxy/mod_proxy.h Tue Nov 29 21:14:08
2011
@@ -88,6 +88,11 @@ enum enctype {
*/
#define DEFAULT_MAX_FORWARDS-1
+typedef struct proxy_balancer proxy_balancer;
+typedef struct proxy_workerproxy_worker;
+typedef struct proxy_conn_pool proxy_conn_pool;
+typedef struct proxy_balancer_method proxy_balancer_method;
Shouldn't those be _t?
-typedef struct proxy_balancer proxy_balancer;
-typedef struct proxy_workerproxy_worker;
-typedef struct proxy_conn_pool proxy_conn_pool;
-typedef struct proxy_balancer_method proxy_balancer_method;
-
They were just moved...
balancer-manager and XML
The XML interface for the balancer manager has, admittedly, lagged behind... Anyone have cycles and/or talent to bring it up to snuff? If not, I'll try to muddle thru it ;)
httpd-trunk: undefined symbols
Hi all, I am currently getting this when attempting to build trunk: Undefined symbols: _ap_proxy_retry_worker, referenced from: _find_best_byrequests in libmod_lbmethod_byrequests.a(mod_lbmethod_byrequests.o) _find_best_hb in libmod_lbmethod_heartbeat.a(mod_lbmethod_heartbeat.o) _find_best_bytraffic in libmod_lbmethod_bytraffic.a(mod_lbmethod_bytraffic.o) _find_best_bybusyness in libmod_lbmethod_bybusyness.a(mod_lbmethod_bybusyness.o) _OCSP_CERTID_dup, referenced from: _stapling_renew_response in libmod_ssl.a(ssl_util_stapling.o) _proxy_module, referenced from: _xlate_name in libmod_proxy_express.a(mod_proxy_express.o) ld: symbol(s) not found Looks like the new proxy stuff might not be 100%? (Not sure of the OCSP_CERTID_dup as yet, I have openssl v1.0.0e from MacPorts, and the native openssl from Snow Leopard, not sure if the two are getting themselves confused) Regards, Graham --
Re: balancer-manager and XML
On Nov 30, 2011, at 9:16 AM, Jim Jagielski wrote: The XML interface for the balancer manager has, admittedly, lagged behind... Anyone have cycles and/or talent to bring it up to snuff? If not, I'll try to muddle thru it ;) As I mentioned to Jim at ApacheCon, I have a 2.2 patch for this that I have been using in production for a couple of years so that we can monitor our balancers. I am in the process of updating this patch for 2.4 right now. I plan to submit the updated patch for discussion/input today. I am just doing some final testing and debugging.
Re: Proposal: error codes
On 27 Nov 2011, at 17:14, Stefan Fritsch wrote: Yes, that would be a good idea and I agree with Daniel that we should use a distinct prefix or format. We currently have around 2700 calls to *_log_?error in trunk, so a 4-digit number should be ok. Together with for example AH as prefix for Apache HTTPD this would result in numbers like AH0815 which don't seem to cause many hits on google. I think most people still use file logging, but Apache httpd does also support syslog. And over the life of Apache httpd syslog has gained features too, such as message codes. http://tools.ietf.org/html/rfc5424 section 6.2.7 says: The MSGID SHOULD identify the type of message. For example, a firewall might use the MSGID TCPIN for incoming TCP traffic and the MSGID TCPOUT for outgoing TCP traffic. Messages with the same MSGID should reflect events of the same semantics. The MSGID itself is a string without further semantics. It is intended for filtering messages on a relay or collector. There is also a mechanism for structured metadata. I don't know whether either or both of these will be written into future Apache httpd… but I thought it was worth mentioning these early on in the discussion. -- Tim Bannister – is...@jellybaby.net
Re: Test failures and libwww-perl 6.0.3
On 29.11.2011 23:23, Stefan Fritsch wrote: On Tuesday 29 November 2011, Kaspar Brand wrote: I have committed the patches in r1207758 (for Apache::Test) and r1207759 (adjustments to the t/ssl tests). Nice, works here now. Thanks. FYI: Torsten pointed out a potential problem with the solution in r1207758, so I have committed a less intrusive approach for set_client_cert() in r1208506. Shouldn't make a difference then running the tests - otherwise let me know. Kaspar
Re: Error codes
On 11/30/2011 2:09 AM, Stefan Fritsch wrote: On Wednesday 30 November 2011, Guenter Knauf wrote: Am 30.11.2011 01:51, schrieb William A. Rowe Jr.: On 11/29/2011 5:30 PM, Stefan Fritsch wrote: Currently my scripts produces: http://people.apache.org/~sf/error-msg-numbers.diff http://people.apache.org/~sf/error-msg-numbers.list This is level info and up, but that is easily changed. Everything from debug level up should be coded. Suggestion, should we allocate numeric ranges per-file, core vs add-on module, so that there is room for expansion? I am not sure that this is necessary. The error log lines already contain the module name or core. You need room for expansion. We will add messages :) If you produced a sequential list of error codes, wouldn't it be more sensical to have all mod_authnz_ldap errors in a contiguous list? I'm not suggesting changing the alpha prefix. Just block out ranges so that any listing of the codes is grouped by module that emits them.
Re: svn commit: r1208378 - in /httpd/httpd/branches/2.4.x: ./ docs/manual/ docs/manual/mod/ include/ modules/aaa/ modules/arch/netware/ modules/cluster/ modules/echo/ modules/filters/ modules/http/ mo
On 11/30/2011 5:03 AM, minf...@apache.org wrote:
+trtdcode%{c}a/code/td
+tdActual remote IP-address and port (see the
+modulemod_remoteip/module module)/td/tr
+
I thought we had this discussion... the words actual and effective
are misnomers. Remote peer IP is what you were attempting to say.
There are not necessarily two; we may have many intermediary hosts.
Peer IP informs the reader that it's the immediate client, and Client
IP informs the reader that it's the most remote client. Let's not
confuse the docs with yet other pejoratives like actual/effective.
Re: svn commit: r1208378 - in /httpd/httpd/branches/2.4.x: ./ docs/manual/ docs/manual/mod/ include/ modules/aaa/ modules/arch/netware/ modules/cluster/ modules/echo/ modules/filters/ modules/http/ mo
On 30 Nov 2011, at 9:23 PM, William A. Rowe Jr. wrote:
On 11/30/2011 5:03 AM, minf...@apache.org wrote:
+trtdcode%{c}a/code/td
+tdActual remote IP-address and port (see the
+modulemod_remoteip/module module)/td/tr
+
I thought we had this discussion... the words actual and effective
are misnomers. Remote peer IP is what you were attempting to say.
There are not necessarily two; we may have many intermediary hosts.
Peer IP informs the reader that it's the immediate client, and Client
IP informs the reader that it's the most remote client. Let's not
confuse the docs with yet other pejoratives like actual/effective.
Entirely happy to change it, would you accept Peer IP address and port?
Regards,
Graham
--
Re: balancer-manager and XML
On Nov 30, 2011, at 10:26 AM, Jim Riggs wrote: On Nov 30, 2011, at 9:16 AM, Jim Jagielski wrote: The XML interface for the balancer manager has, admittedly, lagged behind... Anyone have cycles and/or talent to bring it up to snuff? If not, I'll try to muddle thru it ;) As I mentioned to Jim at ApacheCon, I have a 2.2 patch for this that I have been using in production for a couple of years so that we can monitor our balancers. I am in the process of updating this patch for 2.4 right now. I plan to submit the updated patch for discussion/input today. I am just doing some final testing and debugging. https://issues.apache.org/bugzilla/show_bug.cgi?id=52264
Re: Error codes
On 30 Nov 2011, at 9:21 PM, William A. Rowe Jr. wrote: I'm not suggesting changing the alpha prefix. Just block out ranges so that any listing of the codes is grouped by module that emits them. From my experience, any attempt at grouping some kind of numbering like this normally results a few years later in an attempt to undo the grouping to solve problems caused by the ranges being too small, or running out of numbers of a sensible size. Ideally it should be as simple as possible, run a script and a number will be chosen for you is a lot more convenient, and if a script could warn of duplicated numbers for fixing (think the result of cut-and-paste by someone unfamiliar with the script) that would be ideal too. Regards, Graham --
Re: Error codes
On Nov 30, 2011, at 3:23 AM, HyperHacker wrote: Any reason *not* to use 5 digits? The extra character, or using hex, seems worth the future flexibility. We want to be able to assign new codes, rather than reusing old ones, when error messages change in future versions. Allocating 50 messages to mod_foo might be fine for now, but in httpd version 4.8 we may have all new messages. Not sure we can adequately determine how many is enough to allocate. -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: svn commit: r1070179 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_cache.xml modules/cache/cache_storage.c modules/cache/cache_storage.h modules/cache/mod_cache.c modules/cache/mod_cache.h
On 30 Nov 2011, at 1:30 PM, Graham Leggett wrote: The change has been reverted on v2.4, and the following patch gives the API changes that allow us to fix this in the v2.4 series: Applied in r 1208822 and backported in r1208824. Regards, Graham --
Re: Proposal: error codes
On Wednesday 30 November 2011, Tim Bannister wrote: On 27 Nov 2011, at 17:14, Stefan Fritsch wrote: Yes, that would be a good idea and I agree with Daniel that we should use a distinct prefix or format. We currently have around 2700 calls to *_log_?error in trunk, so a 4-digit number should be ok. Together with for example AH as prefix for Apache HTTPD this would result in numbers like AH0815 which don't seem to cause many hits on google. I think most people still use file logging, but Apache httpd does also support syslog. And over the life of Apache httpd syslog has gained features too, such as message codes. http://tools.ietf.org/html/rfc5424 section 6.2.7 says: The MSGID SHOULD identify the type of message. For example, a firewall might use the MSGID TCPIN for incoming TCP traffic and the MSGID TCPOUT for outgoing TCP traffic. Messages with the same MSGID should reflect events of the same semantics. The MSGID itself is a string without further semantics. It is intended for filtering messages on a relay or collector. There is also a mechanism for structured metadata. I don't know whether either or both of these will be written into future Apache httpd… but I thought it was worth mentioning these early on in the discussion. That's definitely interesting to know, but one has to see if there is a standard API for these things. The Linux man pages of syslog() and friends do not mention MSGID.
Re: Error codes
On Wednesday 30 November 2011, Graham Leggett wrote: On 30 Nov 2011, at 9:21 PM, William A. Rowe Jr. wrote: I'm not suggesting changing the alpha prefix. Just block out ranges so that any listing of the codes is grouped by module that emits them. From my experience, any attempt at grouping some kind of numbering like this normally results a few years later in an attempt to undo the grouping to solve problems caused by the ranges being too small, or running out of numbers of a sensible size. I agree with Graham here. mod_ssl has 300 messages, so the range per module would likely need to be something like 1000, and with 100 modules, this would mean 6 digits in the number. And tracking one counter per module would make my script way more complex. Ideally it should be as simple as possible, run a script and a number will be chosen for you is a lot more convenient, and if a script could warn of duplicated numbers for fixing (think the result of cut-and-paste by someone unfamiliar with the script) that would be ideal too. The current state is here: http://people.apache.org/~sf/log-msg-numbers.diff http://people.apache.org/~sf/log-msg-numbers.list http://people.apache.org/~sf/log-msg-numbers.scripts.diff Changes to previous are - 5 digits instead of 4 - with APLOGNO() syntax (we really want that, just think of all the archives of the svn commit mailing list) - level debug and above instead of info - now after the s/r/c/p argument and not before the format; this makes the script a bit simpler and don't miss logging calls with multi-line format strings. But the number is now frequently on a different line than the format string. I have put the scripts there, too, but they need some cleaning up. Still todo are at least ap_log_cserror, ssl_log_error, dav_log_err, and everything that has a variable as level parameter. What to do about multi-line log messages that are split over several calls to ap_log...()? Grep prefork.c for 'almost certain server failure' for an example. Maybe just add a number to the first line? This is something that will need manual adjustment. I guess before we commit this to 2.4, all other pending backports should be done. Any more comments/thoughts?
Re: Error codes
On 01 Dec 2011, at 1:28 AM, Stefan Fritsch wrote: I guess before we commit this to 2.4, all other pending backports should be done. Speaking for myself, all my backports are done. Regards, Graham --
