After an extra look at log4j source I wonder if I've found some kind of solution: Logger contains the following signature: log.debug(Object message)
Here this is an "Ojbject" and not a "String". If I create some class in charge of building the debug message only when its toString() method is called and I call log.debug() with some instance of that class, then message creation is payed only when log4j actually builds the message. And I believe this to append after filtering if filtering allowed the message to be logged. If I'm correct, this would be a neat solution. What do you guys think about it? >-----Original Message----- >From: ext James Stauffer [mailto:[EMAIL PROTECTED] >Sent: Wednesday, July 19, 2006 5:44 PM >To: Log4J Users List >Subject: Re: High performance filters > >It would really only work with 1 extra criteria. >I don't know the impact of many loggers. > >On 7/19/06, [EMAIL PROTECTED] ><[EMAIL PROTECTED]> wrote: >> That's an interresting work arround. >> Still that is tedious when several criterias are needed. >> >> Since we are talking about a server, that would create a >huge number of loggers. Do you have any idea about performance impact? >> >> >-----Original Message----- >> >From: ext James Stauffer [mailto:[EMAIL PROTECTED] >> >Sent: Wednesday, July 19, 2006 5:22 PM >> >To: Log4J Users List >> >Subject: Re: High performance filters >> > >> >One option would be to include to the IP address in the logger name. >> >Logger log = Logger.getLogger(getClass().getName() + "." + >> >request.getSourceAddress()); >> > >> >That would create many more loggers but would allow >> >log.isDebugEnabled() to work correctly. >> > >> >On 7/19/06, [EMAIL PROTECTED] >> ><[EMAIL PROTECTED]> wrote: >> >> 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] >> >> >> >> >> > >> > >> >-- >> >James Stauffer >> >Are you good? Take the test at http://www.livingwaters.com/good/ >> > >> >>--------------------------------------------------------------------- >> >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] >> >> > > >-- >James Stauffer >Are you good? Take the test at http://www.livingwaters.com/good/ > >--------------------------------------------------------------------- >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]
