Re: Per-module loglevel configuration

On Friday 19 March 2010, Jeff Trawick wrote: > This seems to be the change necessary in most modules: > > +#define APLOG_MODULE_INDEXaccess_compat_module.module_index > > ( > BTW, this one seems to be slightly borked: > +#define APLOG_MODULE_INDEX > optional_hook_import_module=.module_i

Re: Per-module loglevel configuration

On Friday 19 March 2010, Jeff Trawick wrote: > Any thoughts about allowing the conn_rec to hold a logging config > structure which would be consulted when the conn_rec is available, > in order to allow different logging levels per client (whether > implemented by core or by another module)? > >

Re: Per-module loglevel configuration

On Tue, Mar 16, 2010 at 7:29 PM, Stefan Fritsch wrote: > Hi, > > here is the second version of my patch to allow per-module loglevel > configuration. It's available at: > > http://people.apache.org/~sf/per-module-loglevel-v2/ (another tangent based on a quick browse of yo

Re: Per-module loglevel configuration

On Tue, Mar 16, 2010 at 7:29 PM, Stefan Fritsch wrote: > here is the second version of my patch to allow per-module loglevel > configuration. It's available at: > > http://people.apache.org/~sf/per-module-loglevel-v2/ Any thoughts about allowing the conn_rec to hold a logging

Per-module loglevel configuration

Hi, here is the second version of my patch to allow per-module loglevel configuration. It's available at: http://people.apache.org/~sf/per-module-loglevel-v2/ As it's rather big, I have split it into separate logical patches. I hope this makes it easier to review: 0001 Add macro wr

[PATCH] Per module LogLevel configuration

It would be nice if some people could look at the patch and comment if this is a reasonable way to do this. Maybe during the Hackathon? Thanks in advance Stefan On Sunday 03 January 2010, Stefan Fritsch wrote: > I have started an implementation of this: > > http://people.apache.org/~sf/per-modu

Re: Per module LogLevel configuration

Hi, I have started an implementation of this: http://people.apache.org/~sf/per-module-loglevel-1.v1.diff http://people.apache.org/~sf/per-module-loglevel-2.v1.diff The first diff is the infrastructure and the second patch touches nearly every file to set the correct module for logging (and twea

Re: Per module LogLevel configuration

On Tue, Dec 29, 2009 at 1:30 AM, Ruediger Pluem wrote: > On 28.12.2009 18:28, Stefan Fritsch wrote: >> On Monday 28 December 2009, Paul Querna wrote: You describe the internal arg processing.  Keep in mind that fn args aren't conditionally processed, they must be created before bein

Re: Per module LogLevel configuration

On 28.12.2009 18:28, Stefan Fritsch wrote: > On Monday 28 December 2009, Paul Querna wrote: >>> You describe the internal arg processing. Keep in mind that fn >>> args aren't conditionally processed, they must be created before >>> being passed to the function. If we can dodge that with a module

Re: Per module LogLevel configuration

On Monday 28 December 2009, Paul Querna wrote: > > You describe the internal arg processing. Keep in mind that fn > > args aren't conditionally processed, they must be created before > > being passed to the function. If we can dodge that with a module > > query 'is mod_foo at loglevel debug here?

Re: Per module LogLevel configuration

On Sun, Dec 27, 2009 at 11:08 PM, William A. Rowe Jr. wrote: > Dan Poirier wrote: >> >> Looking at log_error_core(), it appears that if the logging level is set >> to disallow a particular message from being logged, that >> log_error_core() returns before doing any argument processing.  So the >>

Re: Per module LogLevel configuration

Dan Poirier wrote: > > Looking at log_error_core(), it appears that if the logging level is set > to disallow a particular message from being logged, that > log_error_core() returns before doing any argument processing. So the > overhead would only consist of a few function calls, and my sense wo

Re: Per module LogLevel configuration

"William A. Rowe Jr." writes: > Dan Poirier wrote: >> "William A. Rowe Jr." writes: >> >>> One thing we should refactor is 'debug' logging. Proper debug >>> logging is log early and often, but there is overhead involved >>> in preparing the args and submitting the log request, only to have >>>

Re: Per module LogLevel configuration

Dan Poirier wrote: > "William A. Rowe Jr." writes: > >> One thing we should refactor is 'debug' logging. Proper debug >> logging is log early and often, but there is overhead involved >> in preparing the args and submitting the log request, only to have >> it fall on deaf ears. >> >> If we are d

Re: Per module LogLevel configuration

"William A. Rowe Jr." writes: > One thing we should refactor is 'debug' logging. Proper debug > logging is log early and often, but there is overhead involved > in preparing the args and submitting the log request, only to have > it fall on deaf ears. > > If we are doing any significant 2.0 refa

Re: Per module LogLevel configuration

Your redesign ideas are interesting, Stefan. One thing we should refactor is 'debug' logging. Proper debug logging is log early and often, but there is overhead involved in preparing the args and submitting the log request, only to have it fall on deaf ears. If we are doing any significant 2.0 r

Re: Per module LogLevel configuration

On Thu, 24 Dec 2009, Paul Querna wrote: On Wed, Dec 23, 2009 at 4:14 AM, Stefan Fritsch wrote: An alternative implementation would be something along the lines of how reconnoiter does logging: This would definitely be

Re: Per module LogLevel configuration

On Wed, Dec 23, 2009 at 4:14 AM, Stefan Fritsch wrote: > Hi, > > when debugging problems, one needs detailed debug logging of the > involved functions. Unfortunately, some modules (especially mod_ssl) > log so much that switching to LogLevel debug in a production > environment is often impractical

Per module LogLevel configuration

Hi, when debugging problems, one needs detailed debug logging of the involved functions. Unfortunately, some modules (especially mod_ssl) log so much that switching to LogLevel debug in a production environment is often impractical. Therefore I think it would be very useful if one could set th