asked on

Advice Required on log4j

Can anyone give advice concerning a sensible strategy for using log4j in a servlet environment? I'm just starting to look at it and its becoming obvious that if I'm going to use it successfully then I need to plan its use carefully.

My application consists of one servlet which acts as a message router, with a number of classes which are called from it. I currently declare one public static logger in the top level servlet and then refer to it through out the application. Is this a sensible thing to do?

I've got two appenders at the moment - one to System.out and one to a file. They have different treshholds and I'm using the configureAndWait method to allow me to switch at runtime.

I'm also hoping to use it as a way of spotting performance problems in the application by logging entry and exit points from methods which I think may be causing me problems. Is there a better way of getting this sort of profiling information - I'm running on HP_UX and have no money to spend it that has any baring on the answer! If there are no profiling tools, am I better to create a new Level ( called Performance or something ) and set it at a level below DEBUG?

Any advice will be gratefully received.

Dave

Jim Cakalic

The recommended usage pattern is typically one static Logger per class -- not for the entire application. This allows finer run-time tuning of logging and permits the Logger (aka Category) to be inserted in the log output to provide some locality of reference w/o resorting to use of the poorly performing introspection mechanism to find class/method name.

Logging on entry/exit of a method is not likely to provide you, I think, with the kind of information that you need. First of all, unless your methods are very poor performers, they are likely not likely to run long enough for you to see a measurable number of milliseconds on each execution. Second, it would be difficult (impossible?) to determine whether it is the logging or your method that is responsible for the measurement. Finally, it would be quite onerous to look at any reasonable measurement log and attempt to gather from it a profile by hand. You'd have to write some log processing tools to aggregate and summarize the results. Even then, you couldn't really be sure of the results, IMHO.

I haven't personally used it, but there is a free load/performance testing tool from Jakarta call JMeter.
http://jakarta.apache.org/jmeter/index.html

You might also look at IBM's Jinsight alphaWorks technology. It is available for free download with a 90-day trial license.
http://www.alphaworks.ibm.com/tech/jinsight

Finally, here's a link to an article at JavaWorld which describes the issues/problems with performance analysis -- I forgot to mention how the garbage collector skews "real-time" measurements -- and discusses the JVMPI (JVM Profiler Interface) with code showing how it can be used to take accurate code timings. Probably worth a look if you are going to need to "grow your own" profiler.
http://www.javaworld.com/javatips/jw-javatip92_p.html

Best regards,
Jim Cakalic

howesd

ASKER

Thanks for that Jim.

My app currently has about 70 classes in it, and it seems like that would become quite awkward to manage if I had a logger for each class. Wouldn't I need a configuration (or properties) file for each class/logger to provide the level of fine run-time control that you speak of?

The app ( which should really have been a soap app but I couldn't figure out how to do it quickly enough ) handles about 12 types of input messages. I'm thinking that may be one logger for each of these messages might be a suitable compromise.

I'm having a little difficulty in working out how the different loggers relate to each other, but I must confess that I haven't spend a lot of time reading the manual or experimenting yet.

As far as your point about entry and exit logging is concerned, I agree with what you say and will look in to the tools you mentioned. My app is not scaling terribly well and just using entry and exit logging did help me to identfy one area of weakness - JDOM schema validation appears to take approx 200 milliseconds when one user is accessing the app, but this degrades to over two seconds once I get 20 simultaneous connections. Also, I've fairly new to Java and I'm fairly confident that I'll be able to write some poorly performing methods of my own :)

Dave

ASKER CERTIFIED SOLUTION

Jim Cakalic

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

howesd

ASKER

Thanks Jim - I spent the time to read the manual and I've got what I think to be a workable way of managing it.

Dave