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]
