Re: Error codes

[Stefan Fritsch <sf...@sfritsch.de>]

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

[Jim Jagielski <ji...@jaguNET.com>]

Just to be pedantic... even lazy consensus isn't that fast (<3days),
but no big deal since we are CTR...

On Dec 2, 2011, at 6:33 PM, Stefan Fritsch wrote:

> On Thursday 01 December 2011, Stefan Fritsch wrote:
>> Any more comments/thoughts?
> 
> As nobody disagreed, this is now in trunk. I intend to commit it to 
> 2.4 tomorrow.
> 
> It's already a big step forward and the finishing touches can be done 
> in 2.4.1.
> 

Re: Error codes

[Stefan Fritsch <sf...@sfritsch.de>]

On Thursday 01 December 2011, Stefan Fritsch wrote:
> Any more comments/thoughts?

As nobody disagreed, this is now in trunk. I intend to commit it to 
2.4 tomorrow.

It's already a big step forward and the finishing touches can be done 
in 2.4.1.

Re: Error codes

[Graham Leggett <mi...@sharp.fm>]

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
--