Re: Change loglevel of "File does not exist" messages

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

On Wed, 5 Oct 2011, Rainer Jung wrote:
> So I also suggest to tone it down to "info" and if it makes sense and
> isn't to risky move the default_handler into the http module.
>
> I would not add a separate config option, because that opens a can of
> worms: everyone has a favourite annoying log message he or she wants to
> tone down. Level "info" for this message is the better default and
> whether there needs to be a separate apparatus to control some message
> levels is another discussion with much bigger impact.

True. But a generic apparatus for even more fine-grained log configuration 
won't happen in time for 2.4.

So, if there is consensous to change the messages to "info", I will commit 
that after waiting a bit more for possible objections. BTW, "debug" would 
be fine for me, too.

Cheers,
Stefan

Re: Change loglevel of "File does not exist" messages

[Rainer Jung <ra...@kippdata.de>]

On 06.10.2011 01:07, Daniel Ruggeri wrote:
> On 10/5/2011 4:18 PM, Stefan Fritsch wrote:
>> True. But a generic apparatus for even more fine-grained log
>> configuration won't happen in time for 2.4.
> 
> I have toyed with the idea of this... do you have suggestions on how
> this might be implemented? One of the ideas I heard (or thought of -
> don't recall) was to implement an error log filter such that messages
> matching a certain regex get dropped. To me that seems like it would be
> very expensive for busier sites, but would serve the purpose for some of
> the user base.

Interesting idea!

Rainer

Re: Fine grained error logging overrides [Was: Change loglevel of "File does not exist" messages]

["William A. Rowe Jr." <wr...@rowe-clan.net>]

On 10/6/2011 1:07 PM, William A. Rowe Jr. wrote:
> 
> On startup, read an arbitrary localization file of source:replacement
> error strings (corresponding to the strings scattered throughout our
> sources).  These obviously include any subst tokens, so the file
> permissions of such a localization file must be as strong as the
> httpd and module binaries themselves.  To keep things simple, I'd
> suggest a trivial format of
> 
> en: File %s not found.
> de:
> <blank line>

[Packing these into a single file implies utf-8 formatting of our error
text, irrespective of the formatting of the %s patterns.  Can we live
with that?  If not, a per language table would be needed to make any
sense of the contents of that file.]

Re: Fine grained error logging overrides [Was: Change loglevel of "File does not exist" messages]

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

On Thu, 6 Oct 2011, William A. Rowe Jr. wrote:

> I've been giving this a bunch of thought, not to 'tune' the messages,
> but simply localize them.  The tuning of messages would be a snap.

> Such a string pointer->replacement lookup could be extended to add various
> flags such as desired log level.
>
> I'll be looking at the cpp to work out extraction of the strings of all
> ap_log calls in our core and modules.
>
> Other thoughts?

It is realistic to have localized error message? Most of the docs 
translations are not up to date and I am not sure if there would be enough 
translators to make it worth the effort.

Also, do we need to re-invent this particular wheel? I am sure there are 
many localization frameworks available. I think significant work would 
need to go into infrastructure that looks for out of date translations and 
makes work easy for the translators.

Fine grained error logging overrides [Was: Change loglevel of "File does not exist" messages]

["William A. Rowe Jr." <wr...@rowe-clan.net>]

I've been giving this a bunch of thought, not to 'tune' the messages,
but simply localize them.  The tuning of messages would be a snap.

My thought is to build two reference tables, the first of replacement
messages hashed by source messages, and the second of replacement
messages hashed by source message pointer.

On startup, read an arbitrary localization file of source:replacement
error strings (corresponding to the strings scattered throughout our
sources).  These obviously include any subst tokens, so the file
permissions of such a localization file must be as strong as the
httpd and module binaries themselves.  To keep things simple, I'd
suggest a trivial format of

en: File %s not found.
de:
<blank line>

Where each line consists of a language code, colon ':', and LWS which
is followed by that language's error message.  The next en: code or
a blank line would terminate parsing for that specific message.

We need to read only one pair of codes at startup, although it is
conceivable to have different error logs using different languages.
Extending the behavior to do this would be pretty trivial.

On every error log invocation, we look up the second pointer->replacement
message table, and if not found, proceed to search for the string in the
first source->replacement table.  If not found, we use the source string,
either way add the entry for the pointer->replacement string hash.  There
is a reasonable penalty on the first lookup.  A btree lookup would really
help with the one time string lookup if the error tables grow quite large.

Such a string pointer->replacement lookup could be extended to add various
flags such as desired log level.

I'll be looking at the cpp to work out extraction of the strings of all
ap_log calls in our core and modules.

Other thoughts?

Re: Change loglevel of "File does not exist" messages

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

On Thu, 6 Oct 2011, Jim Jagielski wrote:
> On Oct 5, 2011, at 7:07 PM, Daniel Ruggeri wrote:
>
>> On 10/5/2011 4:18 PM, Stefan Fritsch wrote:
>>> True. But a generic apparatus for even more fine-grained log
>>> configuration won't happen in time for 2.4.
>>
>> I have toyed with the idea of this... do you have suggestions on how
>> this might be implemented?

I have thought about adding logging subsections for each module, which 
could then be configured separately (like core.client_error:crit ). But I 
then dropped the idea because it would involve lots of complexity that 
would then only be used by 2-3 modules.

>> One of the ideas I heard (or thought of -
>> don't recall) was to implement an error log filter such that messages
>> matching a certain regex get dropped. To me that seems like it would be
>> very expensive for busier sites, but would serve the purpose for some of
>> the user base.
>
> It would be quite expensive to be sure… for some sites, logging
> is the most expensive part of the server.

But regex matches are usually cheaper than logging to disk (especially 
considering the increasing number of CPU cores). So it may have some uses 
if a significant number of messages is filtered out.

Re: Change loglevel of "File does not exist" messages

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

On Oct 5, 2011, at 7:07 PM, Daniel Ruggeri wrote:

> On 10/5/2011 4:18 PM, Stefan Fritsch wrote:
>> True. But a generic apparatus for even more fine-grained log
>> configuration won't happen in time for 2.4.
> 
> I have toyed with the idea of this... do you have suggestions on how
> this might be implemented? One of the ideas I heard (or thought of -
> don't recall) was to implement an error log filter such that messages
> matching a certain regex get dropped. To me that seems like it would be
> very expensive for busier sites, but would serve the purpose for some of
> the user base.

It would be quite expensive to be sure… for some sites, logging
is the most expensive part of the server.

Re: Change loglevel of "File does not exist" messages

[Daniel Ruggeri <DR...@primary.net>]

On 10/5/2011 4:18 PM, Stefan Fritsch wrote:
> True. But a generic apparatus for even more fine-grained log
> configuration won't happen in time for 2.4.

I have toyed with the idea of this... do you have suggestions on how
this might be implemented? One of the ideas I heard (or thought of -
don't recall) was to implement an error log filter such that messages
matching a certain regex get dropped. To me that seems like it would be
very expensive for busier sites, but would serve the purpose for some of
the user base.

> So, if there is consensous to change the messages to "info", I will
> commit that after waiting a bit more for possible objections. BTW,
> "debug" would be fine for me, too. 

+1 for info level

-- 
Daniel Ruggeri