Comments on: Why You Should Use “isDebugEnabled” ?

By: Tech Per

Tech Per — Tue, 30 Sep 2008 14:41:08 +0000

@Suresh:

Yep. Take a look at http://www.nelz.net/roller/nelz/entry/log4j_runtime_configuration

By: Suresh

Suresh — Tue, 30 Sep 2008 12:13:29 +0000

How can I disable log at runtime. I am using log4j.xml file. I am able to generate the logs successfully. But now i would like to on and off this feature. Is there any way to enable and disable the generating logs.

By: 547e44d7969d

547e44d7969d — Sat, 10 May 2008 16:00:27 +0000

547e44d7969d…

547e44d7969dc7fb2ebf…

By: satish

satish — Thu, 08 May 2008 09:15:14 +0000

I tried doing this, as a good practice. But I see that it increases clutter a lot. I am back to plain old log.debug in most cases. I now check isDebugEnabled only when a toString operation is costly in terms of time.

By: Jim LoVerde

Jim LoVerde — Mon, 24 Mar 2008 06:16:40 +0000

Actually, the approach taken by log5j (a wrapper around log4j) offer a much more elegant solution.
http://code.google.com/p/log5j/

Basically, instead of using:

if (log.isDebugEnabled())
log.debug(”variable A is set to ” + myVariableA);

You take advantage of JDK 1.5 syntax and write:

log.debug(”variable A is set to %s”, myVariableA);

Notice that you still get the benefit of not having the String concatenation taking place unless debug is enabled, but now you don’t have to clutter your code with a bunch of if statements.

By: Diego Parrilla

Diego Parrilla — Tue, 11 Mar 2008 08:21:28 +0000

I used the “isDebugEnabled” recommendation early in 1999, 2000 and 2001 with java. But we stopped using it because it did not give us a lot in terms of performance using JVM 1.3. In server side development the database is the bottleneck and the ‘isDebugEnabled’ only makes the code less clear.
I think this is an old fashion tip.

By: Andrey P.Rybin

Andrey P.Rybin — Tue, 11 Mar 2008 08:20:59 +0000

I agree completely with lunatix.

Use http://slf4j.org as logging facade and enjoy its .debug(”very fast logging (if disabled) {}”, myObjWithHeavyToString)

By: Eric Jablow

Eric Jablow — Tue, 11 Mar 2008 00:29:46 +0000

If one has a business reason to do a lot of logging, one can declare an object renderer class in the log4j.xml file, and then one simply writes,

Person p = new Person(”Eric”, “Jablow”);
// …
LOGGER.debug(p); // Uses the declared renderer for Person.

By: Tech Per

Tech Per — Mon, 10 Mar 2008 19:57:40 +0000

I agree completely with Jim.

I, myself, used to wrap my log.debug statements in an isDebugEnabled() call. I don’t anymore. In most, if not nearly all, applications of today, the performance gain will negligible and next to nothing.

I will *much* rather put my emphasis on clearer code, which is easier to write, than to squeezing the last nano-second out of the CPU.

In addition, the (perceived) problem of string concatenation is a hard one to kill, even though at least the last two production JVMs from Sun, have done a great job at making it go away. It was in the “old days”, that this was a problem.

By: Jim

Jim — Mon, 10 Mar 2008 17:16:57 +0000

This is a bad idea. To summarize to points above:

- It confuses the designed intent of isDebugEnabled().
- It unnecessarily clutters up readable code.
- The performance gain is so negligible, that 10 million repetitions are necessary to even notice it. If you are logging >10 million occurences, your logs are worthless

Further, you may not know this, but

log.debug(”this is a test”)

and

log.debug(”this ” + ” is ” + ” a ” + ” test”);

generate identical bytecode. (Try it.)

By: B. Waite

B. Waite — Mon, 10 Mar 2008 16:24:44 +0000

I almost agree with Mark. Almost.

Logs lose utility when you have a multithreaded application running on several machines, each processing hundreds of simultaneous user requests. It’s like playing a combination of poker and 52-pickup at the same time–you just can’t sort out the signal from the noise.

That’s why I created a batch logger. It aggregates all calls into a batch before logging them. This results in each request being output in one chunk. This makes deciphering logs *much* easier.

The logger can be instructed to keep quiet unless a problem occurs, at which point it dumps the offending batch. Our logs are generally empty, except for startup info and errors.

Finally, the batch logger can format the output as HTML. If our app is in debug mode, the log batch is appended to the bottom of each web page. The HTML is rendered per task, and uses JavaScript to allow us to drill down into the call stack.

The end result is that we *rarely* need to look at the logs. If we can reproduce the error, we’ll see the details on page that caused it.

By: Ran

Ran — Mon, 10 Mar 2008 15:45:45 +0000

@Mark: My comment wasn’t directed at you. Rather, it was directed at the author of the article.
However, regarding your comment, I disagree. Debug logs are just for that - debug time. When you’re working on a multi-threaded application (in an application server for example), it’s very hard to follow the flow of the code without logs. However, once you’ve finished the debugging of a specific area - close the debug logs for that area! Not only they clutter your log file (which should, IMHO, be almost clean), but they pose a security risk (since various data is usually written to debug, including session ids, user information and even whole packets).

By: Mark Turansky

Mark Turansky — Mon, 10 Mar 2008 15:36:12 +0000

No, I didn’t miss the point.

I think debug statements are useless, so I wouldn’t litter my code with them or with the log.isDebugEnabled call.

Your mileage may vary, but I’ve not seen many apps that have meaningful debug logs.

By: Ran

Ran — Mon, 10 Mar 2008 15:29:39 +0000

You missed the point of isDebugEnabled().
The withCheck() method should’ve been written like this:
private void withCheck() {
…
if (log.isDebugEnabled())
for (int i = 0; i < 10000000; i++){
log.debug(”this is a test”);
}
}…

The point of isDebugEnabled() is to save loops and temporary object creation for debug purposes when you have no need for the debug log.

By: Mark Turansky

Mark Turansky — Mon, 10 Mar 2008 15:27:52 +0000

Your application logging is largely useless and debug statement just makes for gigs of spam in a log file. It’s snowcrash, unreadable, and useless.

I say omit the debug statements entirely.

By: lunatix

lunatix — Mon, 10 Mar 2008 09:55:39 +0000

use slf4j instead of jcl, and you’ll be able to write logger.debug(”The new entry is {}.”, entry); the price of string concatenation is only payed if log is enable, and you don’t have to write ugly bloat code like isDebugIsEnable()

@see
http://www.slf4j.org/faq.html#logging_performance

By: Stefan

Stefan — Sun, 09 Mar 2008 16:57:44 +0000

@jude: The whole point of adding isDebugEnabled() is not calling a method. Usually you have some string concatenations (or toString calls) in your debug statement. And you don’t need that string (and the garbage for the strinbuffer etc.) when you don’t print it. Thus you need to add a isDebugEnabled() before the debug statement.
Maybe thing will change when closures arrive and the evaluation of the argument for debug can be deferred.

By: jude

jude — Sun, 09 Mar 2008 16:06:35 +0000

instead of having an if statement at every place inside your code wherever you plan to use the logging system , it makes more sense to put the if statement inside the debug method . A strategy could be used to poly morphically control the use of if statement