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: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> 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:[EMAIL PROTECTED]
> >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, [EMAIL PROTECTED]
> ><[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
