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]
