Very nice, indeed, but it doesn't apply to existing logging code neither... Heri
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 19, 2006 6:33 PM > To: log4j-user@logging.apache.org > Subject: RE: High performance filters > > > I tried and this solution works like a charm! > Log4j designers are really clever guys :) > > >-----Original Message----- > >From: ext > >[EMAIL PROTECTED] > >ache.org > >[mailto:[EMAIL PROTECTED] > >gging.apache.org] > >Sent: Wednesday, July 19, 2006 6:26 PM > >To: log4j-user@logging.apache.org > >Subject: RE: High performance filters > > > >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] > > > > > > --------------------------------------------------------------------- > 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]
