logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bender Heri" <HBen...@Ergonomics.ch>
Subject RE: High performance filters
Date Wed, 19 Jul 2006 15:22:15 GMT
I would write a helper class with a static interface:

public boolean static isLoggingEnabled( Logger aLog, Level aLevel ) { ... }

where you check your conditions. The call within code could the look like:

     NDC.push("source-ip=" + request.getSourceAddress());
     if (MyLogHelper.isLoggingEnabled( log, Level.DEBUG )
     {
         log.debug(buildDebugMessage(request));
     }
     // process request and send response ...
     NDCP.pop();

Heri

> -----Original Message-----
> From: Vincent.Bourdaraud@nokia.com 
> [mailto:Vincent.Bourdaraud@nokia.com]
> Sent: Wednesday, July 19, 2006 4:55 PM
> To: log4j-user@logging.apache.org
> Subject: RE: High performance filters
> 
> 
> I'm not sure your proposal solves my problem.
> I'm sorry if my question was not clear enough. Let me try another way:
> 
> Considering the following code snippet
> 
> // the following method is called-back hundred of time
> // per second.
> public void process(Request request, Response response)
> {
>     NDC.push("source-ip=" + request.getSourceAddress());
>     if (log.isDebugEnabled())
>     {
>         log.debug(buildDebugMessage(request));
>     }
>     // process request and send response ...
>     NDCP.pop();
> }
> 
> I need that log.debug(buildDebugMessage(request)) is called 
> only if the logger is in debug mode AND the source-ip within 
> the NDC is 192.168.0.12 (this source cause some trouble to 
> the server in this example), so that it would be possible to 
> turn live servers in debug mode for some (problematic) 
> context and investigate directly in production without 
> killing performances.
> 
> The NDC+Filtering method does not help that much here. It 
> does prevent messages from beeing wrote if they don't match 
> the expected context (source IP 192.168.0.12 in my example), 
> but it does not prevent the debug message from being built 
> (the buildDebugMessage(request) call) which is still quite 
> expensive (and useless in this context).
> 
> I hope this is clear enough :)
> 
> Thanks a lot for your time!
> Vincent.
> 
> 
> 
> 
> >-----Original Message-----
> >From: ext Javier Gonzalez [mailto:jagonzal@gmail.com] 
> >Sent: Wednesday, July 19, 2006 3:44 PM
> >To: Log4J Users List
> >Subject: Re: High performance filters
> >
> >Create separate Loggers for the debug requests, and leave only 
> >those loggers at debug level. Then prepend log.debug() calls 
> >with if(log.isDebugEnabled()), so that the debug messages will 
> >only be created if the particular logger is debug enabled.
> >
> >(I'm not sure I understood your question correctly, though)
> >
> >On 7/19/06, Vincent.Bourdaraud@nokia.com 
> ><Vincent.Bourdaraud@nokia.com> wrote:
> >> Hi all,
> >>
> >> I'm building some kind of server and I use log4j for logging.
> >> For troubleshooting issue I whant to be able to debug some few 
> >> requests only (based on matching criterias) so that it is 
> >possible to 
> >> debug live servers without killing performances.
> >>
> >> I managed to use NDC and filters to do that and it does 
> >well. However, 
> >> filters are actually applied *after* log messages. Then using
> >> NDC+filters solves only half the issue since the debug messages are
> >> still created (even if not logged to disk). And because this 
> >is quite 
> >> CPU and RAM intensive it would drop the performances below 
> >acceptable 
> >> production-level.
> >>
> >> Do you know if there is any way to use a filter-like mechanis at
> >> log.isDebugEnabled() level for example? This way it would be 
> >possible 
> >> to not even build debug messages when the NDC does not match 
> >> criterias, thus saving a lot CPU and RAM usage and allowing 
> >debugging live servers.
> >>
> >> Thanks all,
> >> Vincent Bourdaraud.
> >>
> >>
> >
> >
> >--
> >Javier González Nicolini
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Mime
View raw message